>Hi Walter,
>I tried your version and with repeated calls it has timing around 17-26 secs.

Hmmm, I think there are some other circumstances which make up the difference. Are you referring to Re: Side by side comparison (strings & local data) Thread #861648 Message #861698

My example seems to be about twice as fast as this when testing it with various cursor with different length and width.

Can you put a SET CONSOLE OFF at the beginning (so it does not output the result to the display) and remove the .T. parameter from the TEXTMERGE(cString,.T.) and check the results again ?

>My test is very simple. TestCursor is a simple cursor with few fields of different datatypes and 200K recs. Select into part just selects all records (no filter clause where VFP would show itself more).
>VFP's being interpreted seems to be as a disadvantage at first but after .NET I doubt if interpreting is a bad way or not :)

I'm convinced that intepretating is not a bad thing at all, except for the pure speed at runtime.

Thanks,

Walter,

>Cetin
>
>>Hi Cetin,
>>
>>I don't know what exact test you've done and I don't have to .NET framework up and running here, but can you tell me how fast my solution runs compared the ones you've tested ? I'm just curious.
>>IMO, the main disadvantage of VFP is, is that it is interpretated, however it's advantage is that it has a very large set of powerfull commands that do complex algorithms in just one interpretation call. Hence, I'd like to know how the TEXTMERGE command performs in this case.
>>
>>I've done some benchmarks, and this came as the fastest I could think off.
>>
>>

=AFIELDS(laFields, "Testcursor")
>>StartTime = SECONDS()
>>
>>cString = "<CLIENT>"
>>FOR nT = 1 TO ALEN(laFields,1)
>>	cString = cString +  "<"+laFields(nT,1)+">%%"+laFields(nT,1)+"%%<\"+laFields(nT,1)+">"
>>ENDFOR
>>cString = cString + "\<CLIENT>"
>>
>>SET TEXTMERGE DELIMITERS TO "%%","%%"
>>SET TEXTMERGE TO cXml
>>SET TEXTMERGE ON
>>
>>\<TEST>
>>SCAN
>>	TEXTMERGE(cString,.T.)
>>ENDSCAN
>>\\</TEST>
>>
>>SET TEXTMERGE OFF
>>SET TEXTMERGE TO
>>SET CONSOLE ON
>>
>>
>>cXml = FILETOSTR("cxml.txt")
>>?SECONDS() - StartTime

>>
>>
>>Thanks.
>>
>>Walter,
>>
>>>I also touched to C# code to my knowledge for a faster C# code :
>>>

>>>public static void myTest()
>>>{
>>>	//Use Local FoxDB with lots of data
>>>	string strCon = "Provider=VFPOLEDB.1;Data Source=c:\\myPath";
>>>	string strSQL = "SELECT * FROM TestCursor";
>>>
>>>	//Start time
>>>	DateTime StartTime = DateTime.Now;
>>>	OleDbConnection cn = new OleDbConnection(strCon) ;
>>>	cn.Open();
>>>	OleDbCommand cmd = new OleDbCommand(strSQL,cn);
>>>	OleDbDataReader rdr = cmd.ExecuteReader(CommandBehavior.SequentialAccess);
>>>
>>>	TextWriter wr = new StreamWriter("c:\\myPath\\output.xml");
>>>	wr.WriteLine("<Test>");
>>>
>>>	//Build XML Result
>>>
>>>	StringBuilder rowString = new StringBuilder();
>>>	rowString.Append("\t<CLIENT>\n");
>>>	for (int cl=0;cl < rdr.FieldCount;cl++)
>>>	{
>>>		rowString.Append("\t\t<" +
>>>			rdr.GetName(cl) + ">{" +
>>>			cl.ToString() + "}</" +
>>>			rdr.GetName(cl) + ">\n") ;
>>>	}
>>>	rowString.Append("\t<CLIENT>");
>>>	string strRow = rowString.ToString();
>>>	object[] rowData = new object[rdr.FieldCount];
>>>
>>>	while (rdr.Read())
>>>	{
>>>		rdr.GetValues(rowData);
>>>		wr.WriteLine(strRow,rowData);
>>>	}
>>>	wr.WriteLine("</Test>");
>>>	wr.Close();
>>>	rdr.Close();
>>>        cn.Close();
>>>	Console.WriteLine(DateTime.Now-StartTime) ;
>>>}
>>>

This was exceptionally faster than original version - 17-18 secs. Still far away from VFP's 7-9 secs.
>>>
>>>The main reason VFP is being so fast was on data part as I could test. VFP was making the data ready in less than a second vs C# needed at least 11 secs just for the data (tried that with both a single cursor filling and an empty rdr.Read() loop). If we subtract timing lost on data getting this version does string portion in about 6-7secs which is almost the same timing as VFP's.
>>>
>>>But yet again on my part :)
>>>I wouldn't take a language/tool just with a few tests and I actually don't believe any developer might be using a single language/tool for all of her/his application needs. It's a developer's art to mix languages/tools for their best parts no matter it's directly supported via say CLR or COM or anything like that. I was mixing them in DOS days and would never stop doing so :)
>>>OTOH I wouldn't look into sayings 'Why not a VFP.NET' cold. IMHO they're fairly right in asking that. VB.NET and VC#.NET is not there to match and an another language is needed IMHO. But there are experts in the first 1-2 years and they should know better :) I must be dreaming thinking VFP.NET is possible just by reading inside architecture of .NET.
>>>(I didn't try a C++ version as MS claims all languages are created equal - some are created more equal we know anyways. I really wonder at times if they slowed down the C just to make show VB fast:)
>>>Cetin