speed of LOCATE command in X# vs VFP

[Chris]

Robert,

Caching was what I also thought is the basic difference at first, but then tried with a single iteration in a huge file, so in uncached data, and still the difference is very big compared also to VO, not only FoxPro. I have been preparing a sample and will log it in a minute.

[robert]

Matt,

SQLExec() results are already in memory. So this should give no problems.

Robert

[robert]

Chris,

If I remember correctly then VO caches things differently from what we do at this moment. I remember that there was a special "cache manager" in the runtime.

Robert

[Zdeněk Krejčí]

I would like to note that the LOCATE command in VFP uses Rushmore optimization when possible

[robert]

Zdenek,

We know that, but the example given does not have any indexes so no Rushmore optimization.

Robert

[robert]

Gerhard,

SuspendNotification() and ResetNotification() are handled at the DbServer level.
The example uses workareas / cursors directly

Robert

[Loy2888]

Hi Robert/Chris,

I tried to add

Code: Select all

FConvertToMemoryStream(DbInfo(DBI_FILEHANDLE))

but it only reduced to 6 seconds from 8 seconds. Still slow compared to FoxPro at less than 1 sec.

The reason why the speed is a big deal for me is that I have a real-time system that constantly collects (in endless loop) live status, attributes, locations, positions, etc.. of a certain moving parts on a 20 different tables that are pretty small with less than 1k of records each and index files are not even needed since LOCATE in FOXPRO is fast enough to return the real-time info.

If I run this code in X#, the delay is adding up, and the result is nothing but a delayed information.

I hope this needs to be considered as I have a positive outlook towards X# moving forward.

Loy

[robert]

Loy,

We will certainly look at this.
But I have to tell you that our first priority was and is to add all the features and make your apps work. Improving performance is not priority 1. That does not mean that we will not look at this though.


Robert

[leon-ts]

Hi all,

I was interested in this topic.
Run Loy's example on my computer (several runs to get the average). The test was completed in 10 seconds.
Next, I applied Robert's recommendation with loading the stream into memory.

Code: Select all

FConvertToMemoryStream(DbInfo(DBI_FILEHANDLE))

The test was completed in 1 second.

P.S. I am developing VO/XSharp applications (not a VFP developer). But I take optimizations and application performance very seriously. Therefore, this topic is interesting to me.

[Loy2888]

Hi Leon,
Thanks for being interested on this topic as I am taking application performance very seriously as well. I have applications with heavy lifting algorithms and haven't tried them yet in X# as I came across this performance issue.

Would you mind to test this code as well, it's just the speed of SKIP command for 10 million records, you don't need to create a table with 10 milion records, just a small table will do and go top when eof() see code below:

Code: Select all

? "Start: " + Time()
USE "C:TEMPTemp.DBF" SHARED
//FConvertToMemoryStream(DbInfo(DBI_FILEHANDLE))
SELECT TEMP
GO TOP
FOR VAR lnSERIES = 1 TO 10000000
    SKIP
    IF EOF()
        GO TOP
    ENDIF
NEXT
? "  End: " + Time()

I run this code in X# and it is taking forever, I mean "forever" when it exceeds more than 2 minutes...

In native FOXPRO, running the same code took only 1 second, 2 seconds is the most...

@Robert,

I understand you have more priorities adding all the features in a dialect, but in my opinion, as a developer, I look first at the speed and performance before I continue. All the features can wait. I know you will eventually fix this but most serious developers with database intensive driven applications like to see the performance before they can continue.

I introduced X# to my colleagues showing its cool features and they were very impressed at first, but when we tested X# (using our existing applications) its speed and performance in terms of accessing a table and comparing it to native FoxPro, we were kind of "hmmm... not sure about this".. Anyway, I told them to hold their breath as the X# team is working on it but not the priority right now.

Loy