>------------------------------------------------
>This was the fastest amongst the ones I tested :
>------------------------------------------------
>
>Dudes,
>
>Many interesting points, re relative performance of various techniques and other things, have been made on this thread.
>
>And 'scuse me if *somebody* in all the examples made a point of writing well-formed XML. I may have missed it. AFAICS *none* of you seem to be writing usable code, so the your times all need to be adjusted
.
>
>Since, in both C# and VFP, you are writing your files manually, you have to pay attention to the potential presence of XML markup characters in your data.
>
>All it would take would be one address value such as "North Ave & Main St" in C:\DEV\CSHARP\DEMO\DEMOS\DATA\CLIENT for your results to stop being well-formed XML.
>
>A function call or some other means to XMLEncode each column's contents, changing markup chars to entity references (or, ugh, alternatively by making all the contents CDATA) must be included on all sides of the speed comparison as long as you're writing XML "raw", as you all seem to be doing.
>
>An XML-centric object or language construct (whether XMLAdapter, CURSORTOXML(), Microsoft.XMLDOM, System.Xml.XmlTextWriter, or javax.xml.parsers.DocumentBuilder I don't care!!!) is designed to write XML. Using such an object or function instead of streaming it out yourself may seem, at first glance, to be the slower way of doing things, or be additional overhead you don't need. But it has many advantages: many of these details are taken care of for you.
>
>When you start writing more complex XML (trying to adhere to a more complex schema, IOW), the advantages of such an object become even more clearer -- and sometimes the performance scales actually tip.
>
>I am not trying to dissuade you (any of you) from streaming the files yourselves and writing out the bytes, however you choose to do it. I often do this (in more than one language); sometimes it's the right choice.
>
>Just remember you have to add in the time (and the code) for making sure to write the XML correctly, not just write it, before you report your times.
>
>In general, I agree with whoever on this long, long thread (<s>) said that you have to test in the real-life conditions matching your real-life requirements. Don't get fixated on one method and assume it's the fastest way to do all XML document creation (or all string-handling or all data-traversal), in every situation.
>
>I am not commenting here on the relative speeds of C# and VFP. Only that, within each language, there will be slower and faster ways to do everything and that, within each language, sometimes the way that seems slower is actually better AND EVEN FASTER for certain uses.
>
>And this is just talking about runtime performance, before you start comparing dev times, maintainability, or learning curves <s>.
>
>WITHIN EACH LANGUAGE, there is a lot of variation and a lot of room for judgement calls.
>
>I don't personally see the point of the cross-language comparisons being done here. IMHO they're invariably subjective and there are always tons of factors impacting what is the best tool for any given job, of which runtime performance is only one. But I'm not trying to inhibit you from those comparisons if they serve a purpose for you -- just indicating that I don't have anything to contribute on that subject ;-).
>
>>L<
>
>
>PS I realize that building XML documents does not have to be the goal of your tests. They were supposed to evaluate and compare speed of string handling, file writing, and iterating through data. But still, if your test case is supposed to create XML, please do a proper job.
Lisa,
This thread was in fact connected with another. In that other thread I already stated the points you did just in a few lines.
The job as you noticed has nothing to do with creating XML, just to compare speed of local data engine + string handling on that data.
If you ask my direct opinion I find it funny to cross-compare languages.
If you ask my opinion on XML I find it as a bad gift to computing.
Cetin
