fbpx
Welcome, Guest
Username: Password: Remember me
Hier wird Deutsch gesprochen
  • Page:
  • 1
  • 2

TOPIC:

Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 30 Jun 2021 12:44 #18927

  • comitas2


  • Posts: 16
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 30 Jun 2021 13:19 #18928

    • wriedmann
    • wriedmann's Avatar


  • Posts: 2685
  • 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 Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 30 Jun 2021 13:32 #18929

    • robert
    • robert's Avatar


  • Posts: 2264
  • 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
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 30 Jun 2021 13:34 #18930

    • wriedmann
    • wriedmann's Avatar


  • Posts: 2685
  • Hi Robert,
    I'm really sorry for this wrong information!
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 30 Jun 2021 17:12 #18931

    • Terry


  • Posts: 251
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 30 Jun 2021 21:21 #18932

    • SHirsch
    • SHirsch's Avatar


  • Posts: 228
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 11:00 #18935

    • comitas2


  • Posts: 16
  • 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 …

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 11:29 #18937

    • wriedmann
    • wriedmann's Avatar


  • Posts: 2685
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 11:45 #18938

    • Terry


  • Posts: 251
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 12:36 #18942

    • Chris
    • Chris's Avatar


  • Posts: 2603
  • 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.
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 15:28 #18944

    • Terry


  • Posts: 251
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 17:20 #18947

    • robert
    • robert's Avatar


  • Posts: 2264
  • 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
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 17:35 #18950

    • Chris
    • Chris's Avatar


  • Posts: 2603
  • 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)?
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 01 Jul 2021 20:41 #18954

    • Terry


  • Posts: 251
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 02 Jul 2021 15:29 #18962

    • comitas2


  • Posts: 16
  • 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 …

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 03 Jul 2021 11:36 #18969

    • mainhatten


  • Posts: 197
  • 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 …

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 03 Jul 2021 16:10 #18971

    • robert
    • robert's Avatar


  • Posts: 2264
  • 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
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 03 Jul 2021 17:48 #18972

    • mainhatten


  • Posts: 197
  • 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

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 05 Jul 2021 09:22 #18978

    • comitas2


  • Posts: 16
  • 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

    Please Log in or Create an account to join the conversation.

    Ist der XBase-Datenbanktreiber unter XSharp.Core bereits fertiggestellt? 05 Jul 2021 10:36 #18980

    • Chris
    • Chris's Avatar


  • Posts: 2603
  • 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.
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1
    • 2
    Moderators: wriedmann