xsharp.eu

Hi Chris

Yes. But it's not the size of the dbf, but non-contiguous layout in memory when loading that is, I suspect, the main, but probably not only, problem.

See my response to Stefan.

If my understanding of .Net is correct, contiguous loading will also be dependent on other factors such as number of threads used in original program which would not have been changed in the XPorter; when such threads are called and so on.

So, although Jorg was alerted in respect of larger dbf's, there may be many more factors coming into play than meets the eye.

Terry

Terry,

Terry wrote:Hi Chris

Yes. But it's not the size of the dbf, but non-contiguous layout in memory when loading that is, I suspect, the main, but probably not only, problem.

See my response to Stefan.

If my understanding of .Net is correct, contiguous loading will also be dependent on other factors such as number of threads used in original program which would not have been changed in the XPorter; when such threads are called and so on.

So, although Jorg was alerted in respect of larger dbf's, there may be many more factors coming into play than meets the eye.

This is all speculation. That is why Chris asked for an example.

Robert

comitas2 wrote:Vielen Dank für die Hinweise. Die eingesetzte Version von XSharp ist die 2.8.1 vom 18.05.2021 (die also vom letzten Public Installer). Um ein Beispiel zu geben, muss ich mal schauen, wie ich Teile aus meinem Projekt heraustrennen kann und das vielleicht erst mal auf eine DBF beschränke. Wolfgang schlug vor ‚ein entsprechendes Ticket in Github anzulegen‘ – da weiß ich leider nicht den Weg dazu. Ansonsten kann ich wirklich nur in die Tiefe gehen und die Indexstruktur untersuchen, ab wann es so langsam wird. Also wird die Umstellung auf XSharp doch recht aufwendig …

Don't worry about the git ticket, we will create it ourselves if needed. Only thing needed from you is some way to reproduce the problem in our machines.

I would start by checking if it's every dbf that is that slow, or only specific ones. You also said that the speed problem is happening during reindexing, so I am hoping it is not difficult to simply copy the reindexing code of your real app to a small test app, so that the problem is still reproducible. If it is, then can you please zip and send the test app together with all needed data (dbf etc)?

Robert

Speculation to some extent yes.

But there is what I believe to be sound logic behind it - principally based on the Garbage Collector, what it does and how.

To get the underlying idea clear in my mind I jotted it down in a pdf which runs to about 12 pages. I could post it here if anyone was interested.

If Chris can get a quick example, great. But if not my take on the logic may help.

Terry

Um schon mal ein Zwischenergebnis zu geben, habe ich erstmal im Einzelschrittbetrieb untersucht, welche Muster-Indizierung einer DBF sinnvoll wäre herauszugeben. Die 1.Test-DBF ist mit ca. 4000Datensätzen 1,6MB groß, hat zwei Sortierungen in der CDX:
AAdd(IXB, {"LART+LLAB+LPGE+LVNR", {| | _Field->LART+_Field->LLAB+_Field->LPGE+_Field->LVNR } }) und
AAdd(IXB, {"LART+Upper(LTEXT)",{| | _Field->LART+Upper(_Field->LTEXT) } }).
Die originale Vulcan.exe benötigte 1,1sec und die XSharp.exe 5,2sec (wie 1:4,5).
Die 2.Test-DBF ist mit ca. 900000Datensätzen 70MB groß, hat auch zwei Sortierungen in der CDX:
AAdd(IXB, {"KNR+TNR+SNR+LFDNR+LART+LLAB+LPGE+LVNR+LFN", {| | _Field->KNR+_Field->TNR+_Field->SNR+_Field->LFDNR+_Field->LART+_Field->LLAB+_Field->LPGE+_Field->LVNR+_Field->LFN } }) und
AAdd(IXB, {"LFN+LART+LLAB+LPGE+LVNR", {| | _Field->LFN+_Field->LART+_Field->LLAB+_Field->LPGE+_Field->LVNR } }).
Die originale Vulcan.exe benötigte 15sec und die XSharp.exe 9,55min (wie 1:40).
Ich werde natürlich die 2.Test-DBF herausgeben …

Einer der ersten Tests, die ich mache, wenn ich auf ein Verhältnisse zusammen mit deutlichem Unterschied der # der records sehe, ist den Test der 1:40 Tabelle mit unterschiedlicher # von Datensätzen auf einer Kopie zu wiederholen: immer die Hälfte der großen Tabelle löschen, pack machen und messen.
Wenn das Verhältnis wieder besser wird, je kleiner die Tabelle ist, hat das 2 Vorteile:
1) Ist für den Developer sowohl ein deutlicher Wink mit dem Zaunpfahl, hier muss gesucht werden,denn Bremsen, die mit steigender Datenmenge schlimmer werden, sind so ziemlich das Anti-Pattern für Datenbanken
2) Gibt den Hinweis, auch wenn kein Zugriff auf Vergleichs-Runtime oder sogar Wissen über interne Abläufe des Vergleichssystems vorhanden ist ("Isch habe kein Vulcan oder VO" - komme aus der vfp Ecke - habe aber etwas Ahnung von Optimierungen), besteht die realistische Chance, Ursachen alleine durch Analyse des x# Sourcecodes zu finden - dann können auch andere versuchen, im x# Aufbau was zu lernen und gleichzeitig was Produktives beizusteuern, wenn Sie Beispielcode mit Beispieltabellen profilen/tracen...

meine 0.22€
thomas

comitas2 wrote:Um schon mal ein Zwischenergebnis zu geben, habe ich erstmal im Einzelschrittbetrieb untersucht, welche Muster-Indizierung einer DBF sinnvoll wäre herauszugeben. Die 1.Test-DBF ist mit ca. 4000Datensätzen 1,6MB groß, hat zwei Sortierungen in der CDX:
AAdd(IXB, {"LART+LLAB+LPGE+LVNR", {| | _Field->LART+_Field->LLAB+_Field->LPGE+_Field->LVNR } }) und
AAdd(IXB, {"LART+Upper(LTEXT)",{| | _Field->LART+Upper(_Field->LTEXT) } }).
Die originale Vulcan.exe benötigte 1,1sec und die XSharp.exe 5,2sec (wie 1:4,5).
Die 2.Test-DBF ist mit ca. 900000Datensätzen 70MB groß, hat auch zwei Sortierungen in der CDX:
AAdd(IXB, {"KNR+TNR+SNR+LFDNR+LART+LLAB+LPGE+LVNR+LFN", {| | _Field->KNR+_Field->TNR+_Field->SNR+_Field->LFDNR+_Field->LART+_Field->LLAB+_Field->LPGE+_Field->LVNR+_Field->LFN } }) und
AAdd(IXB, {"LFN+LART+LLAB+LPGE+LVNR", {| | _Field->LFN+_Field->LART+_Field->LLAB+_Field->LPGE+_Field->LVNR } }).
Die originale Vulcan.exe benötigte 15sec und die XSharp.exe 9,55min (wie 1:40).
Ich werde natürlich die 2.Test-DBF herausgeben …

Thomas,
That is exactly what we will do:
- evaluating the index expression for all rows in the dbf
- sorting the index keys
- writing the index to disk
But we need the example data. We did not see this (yet) in our test data. Maybe the index expression (with 9 fields this could result in large keys) is part of the problem. Maybe it is something else.

Robert

Hi Robert

robert wrote: That is exactly what we will do:
- evaluating the index expression for all rows in the dbf
- sorting the index keys
- writing the index to disk
But we need the example data. We did not see this (yet) in our test data. Maybe the index expression (with 9 fields this could result in large keys) is part of the problem. Maybe it is something else.

My post was not targeted at dev team, but to anyone finding a corner where x# performance takes a turn for the worse, esp. if comparison to another runtime shows better perf can be attained.
As code and data are already in place without stripping code down to give focused/well defined minimal code, the users doing such small "experimental" steps will get a clear picture of how important a fix is (steep exponential growth is something Corona made common knowledge) and can give a better description, reducing dev team effort and also perhaps lure others into looking at the matter.

This case for instance is one of the examples I'd go for the "retrofit bindevent" or "baseclass init hook" types described in the BindEvent method wrapper example over in the vfp forum, if it were available in x#, as server and RDD calls and layers are still not a clear or well structured picture near this keyboard

Is a nice way to work without global profiling tools - although I am certain Dotnet is much better in this regard than vfp, as vfp coverage profiler is good for coverage, not timing analysis.

regards
thomas

Hallo Entwicklerteam,
habe soeben eine Zip mit der Index-Testapplikation und der DBF an Robert und Chris gesendet. Ich hoffe Ihr könnt damit arbeiten.
Gruß Jörg

Thanks a lot for the sample Jörg, I see what the problem is, it has to do with the number of fields in the filter expression (yours has more than 10). Vulcan has a very small impact on performance as the number of fields increases, while in X# for some reason the impact is very heavy, in geometric progression. Will create a small sample for Robert to have a look into.