xsharp.eu

Hallo,
nachdem ich mit dem XPorter ein Vulcan-Projekt unter XSharp.Core mit etlicher Fehlerbehebung zum Laufen gebracht habe, bin ich über die Geschwindigkeit bei dem Umgang mit ‚größeren‘ DBF-Datenbanken gestolpert. Ein Neuindizieren (also die Neubildung von CDX aus der DBF) dauert mit der bisherigen Vulcan.exe 38 sec. Dabei werden ca. 260MB Daten über 47 DBF’s verteilt angesprochen. Auf ein und demselben PC wird für den gleichen Indiziervorgang mit der neuen XSharp.exe ganze 44min (!) benötigt. Das heißt mind. 70mal langsamer als Vulcan (es konnten sogar einige Teil-Indexe einer CDX nicht erstellt werden)! Bevor ich in die Tiefe gehe: Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? Wenn nun mir daraufhin empfohlen wird: nimm das BYOR-Vulcan-Modell unter XSharp – dann frage ich mich, da kann ich auch ganz bei Vulcan bleiben!? Oder was habe ich (bitte vorerst kein SQL) für Alternativen?
Gruß Jörg

Hallo Jörg,
hast Du das mit der aktuellen Version probiert?
Nur ein paar Bemerkungen:
- das XSharp-RDD wird in diesen Sinne nie wirklich "fertig" sein, weil nach wie vor dran entwickelt wird
- das RDD von Vulcan dürfte auch immer schneller sein, da es anders als das von X# in managed C++ geschrieben ist, während das von X# in X# selber geschrieben ist. Das bringt u.a. mit sich, dass Vulcan auf 32 Bit limitiert ist, während das RDD von X# in AnyCPU läuft (und theoretisch auch auf anderen Plattformen)
- ein weiterer Unterschied ist, dass X# über managed Funktionen auf das Dateisystem zugreift, während Vulcan (und VO) über lowlevel Funktionen arbeiten.
Da das RDD und die entsprechende Performance für viele hier wichtig ist, wird auch weiter dran gearbeitet. Es reicht, in den Github-Tickets zu sehen, wie viele Tickets noch mit dem Tag RDD versehen sind.
Daher wäre es sicher hilfreich, ein möglichst kurzes Sample bereitzustellen, damit das Team was zum Testen hat - ggf. sogar ein entsprechendes Ticket in Github anzulegen.
Wolfgang

Wolfgang,

This info is not completely correct:
- Only the Vulcan CDX driver is written in (managed) C++. All other Vulcan RDDs are fully managed code.
- The X# RDD system also uses low level IO when running on windows

And Jörg, to answer your question about "staying with Vulcan".
Yes you can do that, but that product is no longer supported and will not work with Visual Studio versions 2017, 2019 and 2022.
To really understand why the Vulcan code is so much faster we would need to see an example. It should be faster (because of the C++ code) but not 70x.

The only reason that I can imagine for this speed difference is that you when have a lot of conditional indexes and that when creating a second or third index the condition for these indexes could be resolved with an index that was created earlier.

Robert

Hi Robert,
I'm really sorry for this wrong information!
Wolfgang

Hi Jorg

I can only comment as an external CSharper.

A program originally written for VO/Vulcan and translated to run under .Net will be running under vastly different environmental conditions to previously.

Your program structure has a greater influence on performance than was ever the case previously and some aspects of the original program structure, which could not have been "optimised away" automatically in the translation process, could well have a very negative impact on preformance.

As Robert says, a degradation factor of 70 is far higher than would be expected. (I'd expect < 1)

It is my guess that distribution of data over 47 DBF's is the root of the problem.

Tackle this and get to XSharp and you'll have a route to the future - including Windows 11!

Terry

Hi Terry,
what is wrong with the number of DBF's? Too many or too less? We have around 130 DBF's. Some of them very small, just a few records, but some are aound 1 GB with more than 1,000,000 records. There should be no problem with the number of DBFs. It's more about the structure of the indexes (as Robert said).

@Jörg: We are using ADS. So there is currently no problem (using local and remote server).

Stefan

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 …

Hallo Jörg,
es sollte sich doch recht einfach feststellen lassen, bei welcher Datenbank/Index der Prozess langsam wird.
Und mit den entsprechenden Index-Ausdrücken sollte sich das nachverfolgen lassen.
Es ist sicher ein Aufwand, aber auf der anderen Seite kannst Du dann davon ausgehen, dass es eine Lösung für dieses Problem gibt.
lg
Wolfgang

Hi Stefan

Yes you are right.

I comment from a C# perspective. To be honest I have forgotten, now, much of original VO.

The point I was trying to make is that 47 dbf's, to me, points to an underlying structure which gives rise to Memory Fragmentation. Memory Fragmentation in turn generates non-contiguous memory layout.

Memory access time is related to this. Not directly, but in a complex way.

Therefore it is not easy to draw any direct conclusions, probably impossible, but vast differences in memory locality can introduce significant performance penalities.

So again, you are right, I did not mean to imply it is the number of dbf's directly, it is how they are loaded into memory. If your 1,000,000 records when sequentially loaded are contiguous in memory there will be no degradation in performance.

It may well be that most of this is related to the structure of the supporting indexes, but the root cause IMO lies a bit deeper.

Terry

Hi Terry,

I have seen X# apps that open 100s of large dbfs and have no issue at all

It's not a problem of many dbfs, it's just that there's apparently a problem in X# coping with the specific code in Jörg's app. I'm pretty sure Robert will be able to improve speed a lot, when he gets a sample reproducing the problem.