XProfan

Nun, XProfan arbeitet im Gegensatz zu Prf5 mit Large-Strings, also Strings die nicht nur 256Chars, sonder sogar 32kB Chars an Länge haben können. Diese Umstellung im String-Wesen kann leider solch Auswirkungen mitsich bringen.

Außerdem müsste sich wohl Roland dazu ein wenig äußern.

Ich habe das mal kurz getestet, und muß zugeben substr ist in xprofan leider 5-Mal langsamer.

Folgenden Code habe ich dafür gepinselt:
Kompilieren Markieren Separieren

print
declare t&,z&,s$,ss$
let t&=&gettickcount
let z&=0
let s$="SO KANNS WEITER| GEHGEN ODER OMIT | DLKFJS LKDFJ SO KANNS NICHT WEITER| GEHGEN ODER OMIT | DLKFJS LKDFJ SO KANNS WEITER| GEHGEN ODER OMIT | DLKFJS LKDFJ SO KANNS WEITER| GEHGEN ODER OMIT | DLKFJS LKDFJ "

while 1

    if gt(&gettickcount,t&)

        let t&=add(t&,1000)
        locate 1,1
        print z&
        let z&=0

    endif

    let z&=add(Z&,1)
    let ss$=substr$(s$,add(mod(z&,10),1),"|")

wend

end

@Frank, wollen wir den substr auf asm-basis beschläunigen? XPSE könnte aus substr ein _asm_substr machen, eine Procedure namens _asm_substr anlegen gefüllt mit einem ASM-Piece von Dir.

@Konrad, wenn Du möchtest schnuddle ich Dir schnell ne kleine Mini-DLL zusammen, die das CSV-Parsen für Dich erledigt. Wäre natürlich um ein Vielfaches zügiger. Müsstest mir nur den Profan-Code geben, der zu übersetzen ist. Den Rest erledige ich schon. Eine mini-beispiel-cvs genau zu diesem Thema wäre zum Testen nötig. Vielleicht ein kleiner Auszug aus der Originalen.

Bis denne, iF

30.06.2004 ▲

Frank
Abbing

Hi,

also ich finde nicht, das die Funktion sooo langsam arbeitet, das man sie sofort ersetzen müßte.
Konrad, was für Strings verarbeitest du denn ?
Ein Beipspiel ?

Konrad
Flachs

Hallo If und Frank,

danke für die schnelle Antwort.

Ich habe festgestellt, das nicht nur substr$ sondern auch mid$ langsamer geworden ist.

Zum Vergleich das einlesen von 20000 csv-Zeilen:

Profan 5.0: ca.27sek.
Profan 8.0: ca.82sek.
Profan 8.0 ohne if und mid$ : 47sek.

Im Programm Teile ich jede Zeile mit z.B. Let rtecomment$ = @substr$(lineinp$,12,;) .
Dann werden die Teile gefiltert mit z.B. Let rtecomment$ = @mid$(rtecomment$,1,12) .... oder einer if-Abfrage.

Die Vergrösserung der maximalen Stinglänge ( von Vers.5.0 zu 8.0) scheint die Verarbeitungszeit von einigen Kommandos zu verlängern.

Ideal wäre natürlich eine Einschränkbarkeit der Stringlänge und einem dadurch resultierenden Zeitgewinn.

Gruss
Konrad

Wie gesagt, oder nen mini-Dll, müsstest nur sagen was die machen soll. Z.b. mir dein Profan-Source geben der langsam läuft. Frei geschätzt würde die DLL nicht 27, sonder 3 Sekunden für das Selbe brauchen.

Bis denne, iF

Frank
Abbing

Hi,

die Listview.dll z.B. benutzt CSV-Dateien und bietet einige Funktionen dafür an.
Ich würde CSV-Dateien auch immer mit Bereichen bearbeiten, nicht mit den langsamen Strings
Wenn du etwas Assembler lernen möchtest, kannst du dir mit dem XPIA selber Funktionen schreiben. Solche Maschinenfunktionen würden nicht 27 oder 3 Sekunden benötigen, sondern nur wenige Millisekunden.

Uwe
''Pascal''
Niemeier

Hallo Leute!

Nur der Vollständigkeit halber:
CSV-Dateien kann man auch ganz gut per ODBC/SQL zu Leibe rücken. Obs schneller ist als die manuelle Methode oder sogar eine ASM-Routine, glaube ich allerdings nicht.

Dafür hat man Sortier- u. Suchmöglichkeiten und u.U. direkten Zugriff auf einzelne Zeilen/Spalten (je nach Dateiaufbau).

SeeYou
Pascal

Jens

Hallo Frank,

selbstverständlich hast Du Dich mit den Geschwindigkeitsangaben nicht vertan, jedenfalls gehe ich davon aus. Überrascht bin ich allerdings total.

Gibt es (selbstverständlich problemabhängige) Faktoren, wie schnell z.B. Profan compiliert im Vergleich zu Profan in c++ übersetzt, zu c++ pur bzw. zu Assembler-Code ist?

Viele Grüße

Jens

Nun, in manchen Angelegenheiten hatte ich einen Faktor von *65000 ermittelt, in anderen z.B. nur *10000. Damit gemeint ist der Unterschied eines (reinen) CPPs (nicht prf2cpp!) im Ggs. zu einer PrfExe. Das sind natürlich alles ca-Angaben. Im Grunde sind die Compilate von hochsprachen (wie z.B. cpp) nicht langsamer, als ASM-Code, da ja die Compiler (unter Berüchsichtigung vieler anderer Faktoren einstellbar mit Compilerschaltern) auch in ASM Compilieren. Es ist aber tatsächlich so, daß wenn man direkt in ASM komponiert man einige unwichtige-Operationen weglassen kann. Auf gut deutsch, wenn ein CPP-Prog in einer Sekunde 1mio mal addiert, würde ein reines asm das vielleicht 10-30% schneller schaffen. Das ist aber auch nur dann so, wenn man als CPPer nicht auf die richtigen Compilierschalter im Source achtet. Da bleibt es dem Programmierer selbst überlassen, kosten und nutzen abzuschätzen, wobei C++ natürlich mit einer leckeren Syntax und wirklich einfachen Befehlsmöglichkeiten lockt. Wenn man aber z.B. nur einen Register 1Mio male addieren muß, dann ist wohl natürlich ASM schneller. So könnte man behaupten, das desto einfacher die Aufgabe, desto mehr lohnt ASM.

Bis denne, iF