Chris wrote: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.
I think this reply from Chris shows why the X# development team stands head and shoulders above other and often larger teams. I am too mainly concerned about the speed of using X# in VS, the Intellisense and how a program executes (performance, working) compared to the Vulcan or VO version.We get closer and closer to a version where there are no important drawbacks in these fields. Which does not mean a very specific situation could cause an issue.
I think it's remarkable that 3 days after posting a question the problem is acknowledged and identified, with a good chance it is solved as soon as the next version.
Chris,
die Hinweise auf zu viele Index-Felder haben mich eine Messreihe zwischen Vulcan.exe und entsprechender XSharp.exe (mit dem Beispielcode den Chris bekam) machen lassen. Dabei habe ich die Indexfelder "KNR+TNR+SNR+LFDNR+LART+LLAB+LPGE+LVNR+LFN" und "LFN+LART+LLAB+LPGE+LVNR“ mit jedem Compiler-Lauf um ein Feld verringert bis am Ende nur noch „KNR“ und „LFN“ übrig waren und zu guter Letzt mit nur noch ein Index und ein Feld „KNR“ verblieben. Hier die Messreihe (DBF ist mit ca. 900000Datensätzen 70MB groß):
(mit Stoppuhr ermittelt, sicher mit ein paar Ungenauigkeiten)
Selbst wenn XSharp nur ein Index mit nur einem Feld erzeugen soll, bleibt es mindestens 40mal langsamer als Vulcan. Vielleicht ist ja Chris bereits einer Lösung auf der Spur!?
Leider können die Anwender nicht auf Indexdateien verzichten und sie müssen auch ab und zu mal erneuert werden…
Gruß Jörg
We are aware of this issue.
The problem is not so much in the number of fields but in the size of the index keys and the fact that these keys have very little trailing spaces. As a result the indexes with large keys generate many more index pages and there seems to be a problem with either the insertion of the keys in the pages or with the page writing.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
That's not what we saw, for just one field the difference between X# and vulcan seems to be small. But indeed, as fields increase, the speed difference increases more and more.
Btw, here's the page of the logged issue, it includes some simple test code for reproducing the problem:
Hallo Jörg,
nachdem das jetzt als Ticket angelegt ist und nachvollziehbar ist, kannst Du davon ausgehen, dass das früher oder später gelöst wird.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Hallo Entwicklerteam,
das ist schön, dass das Problem jetzt als Ticket angelegt und auch nachvollziehbar ist.
Bis zu einer Lösung werde ich die Umstellung auf XSharp erstmal langsamer angehen und mich mit dem ReportPro2 für XSharp beschäftigen.
Gruß Jörg
