<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:x = 
"urn:schemas-microsoft-com:office:excel" xmlns:p = 
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a = 
"urn:schemas-microsoft-com:office:access" xmlns:dt = 
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s = 
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs = 
"urn:schemas-microsoft-com:rowset" xmlns:z = "#RowsetSchema" xmlns:b = 
"urn:schemas-microsoft-com:office:publisher" xmlns:ss = 
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c = 
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:oa = 
"urn:schemas-microsoft-com:office:activation" xmlns:html = 
"http://www.w3.org/TR/REC-html40" xmlns:q = 
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D = "DAV:" xmlns:x2 = 
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois = 
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir = 
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds = 
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp = 
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc = 
"http://schemas.microsoft.com/data/udc" xmlns:xsd = 
"http://www.w3.org/2001/XMLSchema" xmlns:sub = 
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = 
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp = 
"http://schemas.microsoft.com/sharepoint/" xmlns:sps = 
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi = 
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf = 
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf = 
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver = 
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels = 
"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t = 
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = 
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z = 
"urn:schemas-microsoft-com:" xmlns:st = ""><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR>
<STYLE>@font-face {
        font-family: Calibri;
}
@font-face {
        font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
        FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
LI.MsoNormal {
        FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
DIV.MsoNormal {
        FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
A:link {
        COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
        COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
        COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
        COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle17 {
        COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle18 {
        COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle19 {
        COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle20 {
        COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle21 {
        COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle22 {
        COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
        FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
        page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV dir=ltr align=left><SPAN class=000401015-18072008><FONT face=Verdana 
color=#0000ff size=2>Hi Greg,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=000401015-18072008><FONT face=Verdana 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=000401015-18072008><FONT face=Verdana 
color=#0000ff size=2>In my experience even touching the&nbsp;reader with Dim a 
As String&nbsp;= reader.GetString("SomeField") will cause memory to start 
building up.&nbsp;There's no reference to underlying unmanaged object to release 
during reader traversing. Since I'm dealing with cca. million of records there's 
no way to stop trashing the thread. The memory just remains reserved even after 
reader gets Closed, Disposed, nulled, GC.Collect()-ed, connection 
closed/disposed, etc. Maybe there's no help to it, maybe it's simply up to the 
managed wrapper, but I'm curious if there's any workaround to 
this.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=000401015-18072008><FONT face=Verdana 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=000401015-18072008><FONT face=Verdana 
color=#0000ff size=2>Regards,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=000401015-18072008><FONT face=Verdana 
color=#0000ff size=2>Maksim Sestic</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> fdo-internals-bounces@lists.osgeo.org 
[mailto:fdo-internals-bounces@lists.osgeo.org] <B>On Behalf Of </B>Greg 
Boone<BR><B>Sent:</B> Friday, July 18, 2008 17:00<BR><B>To:</B> Carl 
Jokl<BR><B>Cc:</B> FDO Internals Mail List<BR><B>Subject:</B> [fdo-internals] 
RE: SDF 3.0 Memory Leak<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=Section1>
<P class=MsoNormal><SPAN style="COLOR: #1f497d">Why don&#8217;t you try modifying the 
benchmark to stop storing all the attribute values in a single dictionary and 
see what the side effect is? If the memory usage drops to an acceptable level 
then the issue is most likely the benchmark implementation, not the SDF 
Provider.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d">Greg<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Carl Jokl 
[mailto:carl.jokl@keynetix.com] <BR><B>Sent:</B> Friday, July 18, 2008 10:07 
AM<BR><B>To:</B> Greg Boone<BR><B>Subject:</B> RE: SDF 3.0 Memory 
Leak<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">The test for memory 
was not the intention of the benchmark but just a side effect. It was hardly the 
most professional approach but to observe the memory usage I opened windows task 
manager and watched the memory usage of the FDOBenchmark 
process.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">The benchmark reads 
entries up to an arbitary batch size. This is part of the FDOBatch class. Once 
the batch size is reached the time to load that single batch is saved and all 
the data loaded in that batch is discarded. The reason being that if we were to 
test with a really large file of the order of gigabites then the entries could 
not all&nbsp; be loaded into memory. Using batches was supposed to make the test 
scalable up to larger sizes due to the assumption that discarding the data in a 
batch would free up the memory it has occupied ready to load another batch. Bear 
in mind that the benchmark was just about timing how long data took to load and 
not (at least in this version) doing anything with the data. Yesterday evening 
while doing some other mapguide work which had me looking into the C++ 
sourcecode I noted that the Dispose() function would call the C++ delete on the 
native object. This gave me the idea of altering the benchmark code so that both 
the FDO batch and FDO Entry classes would have a dispose method which would 
explicitly go through every map guide value object and call the dispose method. 
My thinking was that perhaps the FDO wrappers to these data objects were being 
garbage collected but the native components which they wrapped were remaining in 
memory and could then explain the memory leak. I put this to the test but having 
put the code in place to dispose of all the value objects the memory usage of 
the application during and after the benchmark were still the same. I also 
endeavoured to explicitly dispose of any FDO classes as soon as they were no 
longer needed be it connections, feature readers, schemas, class definitions. 
Disposing of them explicitly in this way still did not seem to impact on the 
memory used when observing the footprint though task 
manager.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">I am informed by a 
colleague that AutoDesk are in position of some profiling tools which could more 
effectively diagnose what is going on with the memory usage than I am able 
to.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d">Regards<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d">Carl<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Greg Boone 
[mailto:greg.boone@autodesk.com] <BR><B>Sent:</B> 18 July 2008 
14:50<BR><B>To:</B> Carl Jokl<BR><B>Subject:</B> RE: SDF 3.0 Memory 
Leak<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d">Excuse my insistence here, but I 
need to understand the memory read dynamics of the benchmark. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d">So, the benchmark opens a 344MB 
SDF file. It then reads all the features and stores a copy of all the Attribute 
and Geometry values for each feature in memory in a dictionary. Is this the 
case?<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d">What is your expected result in 
this situation. As I read it, memory usage will increase as each feature is read 
and stored in the dictionary, up until memory usage reaches ~340 MB. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d">Greg<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Carl Jokl 
[mailto:carl.jokl@keynetix.com] <BR><B>Sent:</B> Friday, July 18, 2008 9:43 
AM<BR><B>To:</B> Greg Boone<BR><B>Subject:</B> RE: SDF 3.0 Memory 
Leak<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">This was the intent 
but on it&#8217;s own doing this isn&#8217;t of great value. The idea is to time how long 
loading takes so it performs a loading operation from and SDF file times how 
long it takes to load the contents of the file while discarding the data once it 
has loaded. The time here on it&#8217;s own isn&#8217;t very useful but for the benchmark 
and identical set of data was stored in a PostGIS database and the time taken to 
load the contents of the SDF file through the SDF FDO provider were compared 
with the time taken to load identical data from the PostGIS database through the 
PostGIS provider.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">The times were then 
compared to see how the retrieval times compared. I was expecting PostGIS to be 
a bit slower because the SDF just had to read in from a Flat file and this would 
likely be happening in the same process as the calling benchmark. By comparison 
the PostGIS data is in a PostGIS database running in it&#8217;s own process and piping 
data out over TCP/IP. That was bound to be extra overhead vs the SDF provider. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">The point of the 
benchmark was that at Keynetix we are migrating a legacy MapGuide 6 application 
to MapGuide enterprise. As part of this migration the question of the best way 
to store the migrated data came up. The options are to continue using SDF flat 
files, use PostGIS, use SQLServer or if we really had lots of money to use 
Oracle. To help make that&nbsp; kind of decision I was asked to try and compare 
the speed of data manipulation from the various data sources. If I had time I 
would have done reading, writing and querying etc as was my original intention. 
As I went through development however I was put under increasing pressure just 
to get some figures back and so I just implemented reading in this 
version.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">The benchmark showed 
that the PostGIS FDO provider was much much slower than SDF, far more so than I 
expected. I was a bit suspicious of this and so wrote a test Java program to 
load the same data directly via JDBC as well as using PostGIS with PGAdmin and 
running queries&nbsp; and that was much much faster (the Java program was able 
to load the data faster than the SDF provider).<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">This as well as some 
log analysis on PostGIS pointed the speed problems to most likely be caused by 
the quality of the PostGIS fdo provider implementation.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">By this point the 
benchmarks had served their purpose for the most part. It was dug out again when 
my colleague was writing a migration application to migrate our legacy SDF 2.0 
data to SDF 3.0. This also used FDO in parts but was plagued by the Memory out 
of error problem. When that was discovered I dug out this benchmark application 
to see if it too had problems with escalating requirements for memory. I found 
that it did albeit not to the point of having a memory out of error exception. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">I hope that explains 
what the code was for. I commented out the PostGIS benchmark as it will not be 
of much use to you unless you have a PostGIS data source to test with but that 
provider did not appear to have a memory leak problem that I could tell. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d">Regards<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB style="COLOR: #1f497d">Carl 
&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Greg Boone 
[mailto:greg.boone@autodesk.com] <BR><B>Sent:</B> 18 July 2008 
14:22<BR><B>To:</B> Carl Jokl<BR><B>Subject:</B> RE: SDF 3.0 Memory 
Leak<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal>Can I ask what is the ultimate purpose of the Benchmark code? 
After looking at the source code, it seems that the benchmark opens the SDF 
file, reads all the features, both attributes and geometry values, and stores 
them in memory. Is this the intent?<o:p></o:p></P>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal>Greg<SPAN style="COLOR: #1f497d"><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN style="COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Carl Jokl 
[mailto:carl.jokl@keynetix.com] <BR><B>Sent:</B> Friday, July 18, 2008 9:04 
AM<BR><B>To:</B> Greg Boone<BR><B>Subject:</B> SDF 3.0 Memory 
Leak<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal><SPAN lang=EN-GB>Greg<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>I attach a copy of the benchmark test 
program. I apologise that it is not as well structured as I would like as I was 
under pressure to get some results back quickly and originally the benchmarks 
were going to cover reading writing querying and removing etc. In the end only 
reading was implemented. The idea was that there is an FDOBenchmark class. Each 
specific FDO provider would have its own subclass which implements setting up an 
FDO connection to that source in the way that specific provider needs to but 
with the actual benchmark tests executing in the common base code to make the 
test as fair as possible.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>The individual benchmarks ended up being 
instantiated in the BenchmarkRunnerForm code behind. It was originally intended 
&nbsp;to be cleaner that this with a specific benchmark runner class doing this 
kind of thing but this was a quick shortcut to save time because I was under 
pressure to get some results data. <o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>There is a line in the 
BenchmarkRunnerForm.cs:<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">_sdfBenchmark = <SPAN 
style="COLOR: blue">new</SPAN> <SPAN 
style="COLOR: #2b91af">SDF3Benchmark</SPAN>(<SPAN style="COLOR: blue">new</SPAN> 
<SPAN style="COLOR: #2b91af">FileInfo</SPAN>(<SPAN 
style="COLOR: #a31515">"E:\\llWater.sdf"</SPAN>), <SPAN 
style="COLOR: blue">new</SPAN> <SPAN 
style="COLOR: #2b91af">FileInfo</SPAN>(<SPAN 
style="COLOR: #a31515">"D:\\testing_file.sdf"</SPAN>));<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>You will have to change this line to point 
to whatever SDF 3 data file you are going to use to test with as I don&#8217;t think 
you would want me attaching the 344mb llWater.sdf to this email. The second 
parameter was for use<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>In the writing benchmark test but as that 
did not get implemented then changing it does not really matter. I think that 
all that happens in the code is that it may check for the presence of the second 
file and delete it if it exists so as to create a fresh destination file as part 
of the test.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>If you need anything else please let me 
know.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB>Carl Jokl<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=EN-GB><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
lang=EN-GB>Keynetix<o:p></o:p></SPAN></P></DIV><BR><BR>__________ NOD32 3278 
(20080718) Information __________<BR><BR>This message was checked by NOD32 
antivirus system.<BR><A 
href="http://www.eset.com">http://www.eset.com</A><BR></BODY></HTML>