Performancevergleich von C, C++, MS VC++, VB6 und noch einige Fragen!



  • Hallo!

    Ich schreibe zurzeit ein Komprimierungstool in VB 6.0. Leider ist die Performance von VB, speziell bei großen Dateien (für die das Programm hauptsächlich eingesetzt wird), relativ schlecht.
    Nun habe ich mir gedacht das Tool, zumindest zum Teil, auf C bzw. C++ zu portieren und die Kompressionsfunktion als DLL zu exportieren und in VB zu verwenden, da eine 50MB Datei ca. 20 Tage zum Komprimieren brauchen würde (dafür ist der Kompressionsfaktor hölle 😉 ). Nun meine Fragen:

    1. Wie stark unterscheidet sich C bzw. C++ im Vergleich zu VB6 performancemäßig? Ich will nur einen ungefähren Faktor wissen (z.B.: 2x, 5x, 10x, ... 100000x)!
    2. Wie stark unterscheidet sich C von C++ performancemäßig (da ich relativ laufzeiteffizient arbeiten muss)?
    3. Ist Visual C++ langsamer als "normaler" C/C++ Code der von anderen Compilern kompiliert wurde? Da Visual C++ auf die .NET-Architektur aufsetzt und die meiner Meinung nach relativ überladen und langsam ist?
    4. Wie groß ist der Performanceverlust beim Aufruf einer Funktion in einer DLL? Ich will nämlich (wie oben beschrieben) die Kompressionsalgorithmen in C/C++ schreiben und diese als DLL exportieren und sie dann in VB aufrufen? Das Problem ist, dass ich immer nur 8KB komprimieren kann (d.h. Bei einer 50MB Datei müsste ich die Komprimierungsfunktion (aus der DLL) tausendemale aufrufen. Würde das meinen Geschwindigkeitsvorteil wieder zunichte machen oder ist der Aufruf einer Funktion die in einer DLL ist (laufzeitmäßig) eher unproblematisch?
    5. Kennt ihr vielleicht Bibliotheken mit Komprimierungsverfahren? (Speziell würde mich LZW/LZ78/LZ77 und Huffman interessieren!)
    6. Gibt es große Performanceunterschiede (von der Laufzeit her) zwischen den einzelnen Kompilern (z.B.: MS, Intel, gcc,...) bei C/C++/MS VC++?

    Vielen Dank für eure Mühen!

    mfg



  • Was du bei MSVC++ nicht nutzt, zieht dir auch nicht am Bein.

    Allerdings gibt es innerhalb der VC++ Reihe schon beachtliche Unterschiede.
    Z.B. optimiert die alte Version 6 (NonPro) nicht und wird um Längen von den neueren Versionen (>7.0) geschlagen, die alle optimieren können und vor allem für neuere Prozessoren als Pentium I.

    Ansonsten meine Standardantwort für alle Optimieraufgaben, die ich mal vor Jahren in einem Buch über Lowlevel-Optimierung las: Assume nothing!
    Probier's halt aus. Es gibt zu viele Faktoren, als das man vorher sagen könnte.



  • Possessed schrieb:

    Nun habe ich mir gedacht das Tool, zumindest zum Teil, auf C bzw. C++ zu portieren und die Kompressionsfunktion als DLL zu exportieren und in VB zu verwenden, da eine 50MB Datei ca. 20 Tage zum Komprimieren brauchen würde (dafür ist der Kompressionsfaktor hölle 😉 ).

    Ich würde mal sagen, dass liegt hauptsächlich an deinem Algorithmus bzw. deiner Umsetzung und nicht an VB6.



  • Nur mal eine Frage, weil ich mich letztens auch mit Kompression beschäftigt hab: Wie gut komprimierst du denn? Besser als rar oder zip?
    Und weißt du zufällig, welche Komplexität dein Algorithmus hat?

    Und, letzte Frage, ist der Open-Source? 😃



  • einen Benutzernamen schrieb:

    Possessed schrieb:

    Nun habe ich mir gedacht das Tool, zumindest zum Teil, auf C bzw. C++ zu portieren und die Kompressionsfunktion als DLL zu exportieren und in VB zu verwenden, da eine 50MB Datei ca. 20 Tage zum Komprimieren brauchen würde (dafür ist der Kompressionsfaktor hölle 😉 ).

    Ich würde mal sagen, dass liegt hauptsächlich an deinem Algorithmus bzw. deiner Umsetzung und nicht an VB6.

    Das das zu einem gewissen Teil an meinem Algorithmus liegt ist mir klar, allerdings arbeite ich viel mit Bits und Bytes herum und schneide oft Zeichen aus einem String, füge neue hinzu und da sind die (intern wahrscheinlich mit Listen implementierten) variablen Strings von VB nicht die beste Lösung. Außerdem ist speziell ein Schritt extrem langsam, jedoch bringt genau dieser eine ziemlich starke und konstante Komprimierung und deswegen habe ich mir gedacht ich schreibe diesen Teil in C/C++ und exportiere ihn als DLL. Jedoch bevor ich mir jedemenge unnötiger Arbeit antue, habe ich mir gedacht, ich frage einfach einmal, ob sich das überhaupt auszahlt?

    mfg



  • Gibt es denn VB gar keine Möglichkeit, da irgendwie C/C++ oder Assembler Code inzulinen?

    Wäre doch das beste, wenn es nur um ein, zwei Schritte zum Beschleunigen geht.



  • Badestrand schrieb:

    Nur mal eine Frage, weil ich mich letztens auch mit Kompression beschäftigt hab: Wie gut komprimierst du denn? Besser als rar oder zip?
    Und weißt du zufällig, welche Komplexität dein Algorithmus hat?

    Und, letzte Frage, ist der Open-Source? 😃

    Naja, klingt ziemlich krank aber meist bringe ich Kompressionsraten von 90%-95% hin (letztens habe ich sogar 99,7% geschafft!!!!!!). Allerdings ist der Algorithmus extrems auf unseren Anwendungsfall spezialisiert und diese ergebnisse habe ich bei relativ kleinen datein bekommen (wie gesagt die 500 MB Datei würde ca. 20 Tage brauchen).
    Prinzipiell würde er auch ganz normale Datei komprimieren können, jedoch höchstwahrscheinlich bei weitem schlechter als zip oder rar Files. Falls du dich wirklich näher interressiert, kannst du ja nochmal zurückschreiben und ich kann dir dann per mail, icq,... das ganze etwas detaillierter erklären, jedoch will ich das hier nicht, da das den rahmen bei weitem sprengen würde.

    wegen der komplexität: zurzeit sind es ungefähr 5000 zeilen vb code, jedoch kommen da noch ein paar sachen dazu, falls sich das mit der performance einigermaßen vernünftig lösen lässt.

    mfg



  • Komprimieren = Byte Klauben
    Byte Klauben in VB = laaaaaaaangsam
    -> (daraus folgt)
    Byte Klauben in VB = doof
    -> (daraus folgt)
    doch lieber C oder C++ verwenden 😉

    Gibt es denn VB gar keine Möglichkeit, da irgendwie C/C++ oder Assembler Code inzulinen?

    Nope. Du kannst COM verwenden, du kannst (recht umständlich) DLL Funktionen aufrufen, und das war's dann auch schon.

    Ob es gescheiter ist die Funktionalität in eine C-kompatible DLL zu packen (die man dann aus VB heraus aufrufen kann), oder gleich eine COM Klasse zu machen ... hängt wohl davon ab wie man das Teil einsetzen will. Also z.B. ob man nur Files auf der Platte komprimieren will oder auch BLOBs im Speicher, ob man nur ein Programm schreiben will was den Code benutzt oder das Ding u.U. sogar weitergeben, evtl. sogar aus .NET verwenden etc.
    Je flexibler es einzusetzen sein soll desto mehr spricht IMO für COM.

    Wenns nur schnell gehen soll dann eher eine einfach DLL.



  • hustbaer schrieb:

    Komprimieren = Byte Klauben
    Byte Klauben in VB = laaaaaaaangsam
    -> (daraus folgt)
    Byte Klauben in VB = doof
    -> (daraus folgt)
    doch lieber C oder C++ verwenden 😉

    Genau das meinte ich und darum meine Frage, ob ich das am besten in C, C++ oder MS VC++ schreiben soll? Ich will nicht die lezte Nanosekunde aus dem Code rausholen, aber wenn C doch um einiges schneller ist, dann würde ich C nehmen, obwohl mir C++ eher zusagen würde, da ich mein letztes C-Programm vor ca. 3 Jahren geschrieben habe und ich in letzter Zeit ausschließlich mit objektorientierter Programmierung beschäftigt habe und ein Umstieg auf C eine relativ große Umstellung wäre.

    Gibt es denn VB gar keine Möglichkeit, da irgendwie C/C++ oder Assembler Code inzulinen?

    Nope. Du kannst COM verwenden, du kannst (recht umständlich) DLL Funktionen aufrufen, und das war's dann auch schon.

    Ob es gescheiter ist die Funktionalität in eine C-kompatible DLL zu packen (die man dann aus VB heraus aufrufen kann), oder gleich eine COM Klasse zu machen ... hängt wohl davon ab wie man das Teil einsetzen will. Also z.B. ob man nur Files auf der Platte komprimieren will oder auch BLOBs im Speicher, ob man nur ein Programm schreiben will was den Code benutzt oder das Ding u.U. sogar weitergeben, evtl. sogar aus .NET verwenden etc.
    Je flexibler es einzusetzen sein soll desto mehr spricht IMO für COM.

    Wenns nur schnell gehen soll dann eher eine einfach DLL.

    Zur Zeit sieht es so aus:
    Das Programm liest eine Datei ein (zurzeit noch komplett, später wird man die Größe die eingelesen werden soll angeben können z.B: 50MB). Danach wird die eingelesene Datei in 8KB Stücke zerhäckselt und die einzelnen Stücke der Komprimierungsfunktion vorgeworfen. (Eine Erklärung warum die 8KB ist relativ schwierig, wobei ich auch dafür wäre die Größe zu erhöhen um die Funktion (die hoffentlich bald in einer DLL ist) seltener aufzurufen, aber da muss ich noch mit meinem big boss reden). Nachdem die einzelnen Stücke wieder aus der Komprimierungsfunktion zurückkommen werden sie wieder zu einem langen String zusammengestoppelt und in eine Datei geschrieben. (Dies sollte nur kurz zur ungefähren erläuterung des programmes dienen.)

    Mit .NET soll es nichts zu tun haben / kommunizieren können. Es sollte nur möglichst schnell sein. D.h. dein Vorschlag wäre ein DLL zu verwenden? Ist dieser Umweg von VB über die DLL ein großer Geschwindigkeitsverlust, da die Oberfläche bereits in vb geschrieben ist und ich diese auch verwenden will. Nur wenn der Zugriff auf eine DLL zu langsam ist, dann werde ich wohl nicht darum herum kommen das ganze auf C/C++ zu portieren. Zur zeit sieht mein plan so aus, dass ich die oberfläche in vb schreibe und die performance-kritischen teile in eine dll (die in C/C++/MS VC++ geschrieben ist) auslagere.

    Übrigens ich bin beeindruckt von eurer hilfsbereitschaft, hätte nicht gedacht, dass hier so schnell soviel antworten. Also danke nochmal!!!

    mfg



  • Ja, wäre total nett, wenn du mir das bissl genauer erklären kannst! Meine Mail-Adresse ist ed.beW[at]smleHlehciM (rückwärts :)).

    Mit Komplexität meinte ich übrigens etwas anderes 😉 Und zwar, wie das Laufzeitverhalten ist, also linear, quadratisch oder so, in Abhängigkeit von der Eingangsgröße (hier Größe der Datei). Wenn du z.B. eine doppelt so große Datei nimmst und die Komprimierung auch doppelt so lange dauert, ist es linear. Wenn die Datei doppelt so groß ist und die Komprimierung viermal so lange dauert, nimmt die Laufzeit quadratisch zu. So halt 🙂



  • erstmal geschwindigkeitsunterschied c zu c++: es gibt keinen grundsätzlichen. nur gibt es viele konstrukte, die in c++ harmlos aussehen, aber sehr aufwendig sind. will heißen, wenn du sauber c++ programmierst und tatsächlich das umsetzt, was du in c auch gebaut hättest, sind sie circa gleich schnell. wenn du eine barocke klassenhierachie baust, wird c++ wohl langsamer sein.

    zur geschwindigkeit von dll-aufrufen, die spielen eine sehr untergeordnete rollen, wenn du eine high-level-api exportierst. also bspw. im pseudo-code: stream compress(anderer_stream) oder gar nur void compress(string dest_filename, string src_filename).
    wobei man letzteres sehr leicht über das erste implementieren kann und daher sinnvollerweise beide nehmen sollte. wie und ob das mit einem vb-frontend sinnvoll möglich ist, musst du selber schauen. sollte aber gehen, da vb eigentlich das gleiche file-handling hat und strings (zumindest c-strings) eigentlich nie ein problem sind.



  • Badestrand schrieb:

    Ja, wäre total nett, wenn du mir das bissl genauer erklären kannst! Meine Mail-Adresse ist ed.beW[at]smleHlehciM (rückwärts :)).

    Mit Komplexität meinte ich übrigens etwas anderes 😉 Und zwar, wie das Laufzeitverhalten ist, also linear, quadratisch oder so, in Abhängigkeit von der Eingangsgröße (hier Größe der Datei). Wenn du z.B. eine doppelt so große Datei nimmst und die Komprimierung auch doppelt so lange dauert, ist es linear. Wenn die Datei doppelt so groß ist und die Komprimierung viermal so lange dauert, nimmt die Laufzeit quadratisch zu. So halt 🙂

    Oh, sorry. ich dachte du wolltest ca. wissen wie viel zeilen das ding hat.

    Prinzipiell ist das Laufzeitverhalten annähernd linear. es wird bei großeren datei (im verhältnis) zwar etwas länger brauchen als mit kleinen, jedoch dürft dieser unterschied nicht signifikant ausfallen.

    wegen deiner frage zur genaueren erläuterung des algorithmus:
    ich kann dir gerne den ungefähren ablauf erklären, jedoch sage ich dir gleich, dass es dir wahrscheinlich nicht viel für deinen komprimierungsalgorithmus bringt, wenn du die funktionsweise von meinem kennst, da dieser wie gesagt sehr spezialisiert ist.
    Falls du nur rein prinzipiell an dem hintergrund wie ich es gemacht habe interessiert bist, kann ich dir vielleicht ein kleines word-file zusammenschreiben und dir das grundlegende erklären. aber wie gesagt glaube nicht, dass dieser algorithmus für jede art von datein so super funktioniert.

    mfg



  • Possessed schrieb:

    wegen deiner frage zur genaueren erläuterung des algorithmus:
    ich kann dir gerne den ungefähren ablauf erklären, jedoch sage ich dir gleich, dass es dir wahrscheinlich nicht viel für deinen komprimierungsalgorithmus bringt, wenn du die funktionsweise von meinem kennst, da dieser wie gesagt sehr spezialisiert ist.
    Falls du nur rein prinzipiell an dem hintergrund wie ich es gemacht habe interessiert bist, kann ich dir vielleicht ein kleines word-file zusammenschreiben und dir das grundlegende erklären. aber wie gesagt glaube nicht, dass dieser algorithmus für jede art von datein so super funktioniert.

    Ja, mich interessiert ja nur, wie genau du den gemacht hast und für welche speziellen Daten der ist. Brauchst dir aber für mich nicht so viele Mühe zu machen, ein bisschen Erklärung würden schon genügen, mach dir keine Umstände 😉



  • wenn ich mir die fragen des op so anschaue wird die darlegung der details seines algorithmus bestimmt ernüchternd, aber naja...

    zum thema: mit msvc++ fährst du tendenziell am besten. unter windows definitiv ungeschlagen was das preis/leistungsverhältnis angeht (express-version), definitiv ein solider compiler, der schnellen code erzeugen kann.

    .net wird dir nicht aufgezwungen, das musst du explizit anfordern.



  • Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • @Possessed:

    Was C vs. C++ angeht: ziemlich egal, solange du *schnellen Code* schreibst. D.h. keine dynamischen Speicheranforderungen in kritischen Schleifen, keine unnötigen virtual Calls, kein std::string, keine std::list (in kritischen Schleifen) etc.

    Ob es sich auszahlt z.B. IO noch direkt in C++ zu machen hängt wohl hauptsächlich davon ab wie schnell der Compressor ist. Wenn du z.B. nicht über 100MB/min kommst, dann zahlt es sich wohl eher nicht aus IO mässig irgendwas zu optimieren. Wenn du auf 10, 20, 50MB/sec kommst, dann zahlt es sich ziemlich sicher aus.

    Vorschlag: schnapp dir den MSVC 8.0 (SP1), schalte inlining, link time code generation und "favor fast code" ein, und schreib halt "schlanken" Code.



  • @hustbaer: Danke, genau solche Tipps habe ich gesucht!!!!

    hustbaer schrieb:

    @Possessed:

    Was C vs. C++ angeht: ziemlich egal, solange du *schnellen Code* schreibst. D.h. keine dynamischen Speicheranforderungen in kritischen Schleifen, keine unnötigen virtual Calls, kein std::string, keine std::list (in kritischen Schleifen) etc.

    Dumme Frage: Aber was spricht gegen std::string??? Das wird doch intern wohl mit einem Array implementiert sein, oder etwa mit Listen, denn dann könnte ich deine einwände verstehen? Wenn es jedoch wirklich mit Array implementiert ist, wie soll ich es besser machen?

    hustbaer schrieb:

    Ob es sich auszahlt z.B. IO noch direkt in C++ zu machen hängt wohl hauptsächlich davon ab wie schnell der Compressor ist. Wenn du z.B. nicht über 100MB/min kommst, dann zahlt es sich wohl eher nicht aus IO mässig irgendwas zu optimieren. Wenn du auf 10, 20, 50MB/sec kommst, dann zahlt es sich ziemlich sicher aus.

    Ne, an die unten genannten Raten werde ich wohl nicht rankommen, eher noch langsamer als das weiter oben genannte.

    hustbaer schrieb:

    Vorschlag: schnapp dir den MSVC 8.0 (SP1), schalte inlining, link time code generation und "favor fast code" ein, und schreib halt "schlanken" Code.

    Danke für diese Tipp!!!

    @Badestrand:
    Ich werde dir morgen etwas zusammenschreiben und per Mail schicken. Ich hoffe ich komme morgen dazu, heute ist mir etwas dazwischen gekommen. Achja, ich habe eine komische Mail-Adresse (d02056@...). Ich wollte es dir nur sagen, da schon einige Leute geglaubt habe das sei Spam und haben meine Mails gelöscht.

    gleich kommts schrieb:

    wenn ich mir die fragen des op so anschaue wird die darlegung der details seines algorithmus bestimmt ernüchternd, aber naja...

    zum thema: mit msvc++ fährst du tendenziell am besten. unter windows definitiv ungeschlagen was das preis/leistungsverhältnis angeht (express-version), definitiv ein solider compiler, der schnellen code erzeugen kann.

    .net wird dir nicht aufgezwungen, das musst du explizit anfordern.

    Zu deinem Post wollte ich nocheinmal gesondert Stellung nehmen. Ich kann mir gut vorstellen das die Fragen die ich hier stelle für euch eher "Noob"-Fragen sind und eher darauf hindeuten, dass ich keine Ahnung habe. Fakt ist, dass ich jedoch meist mit der "normalen" Anwendungsprogrammierung in C# zu tun habe und dort es relativ egal ist ob die eine Funktion ein bißchen länger dauert oder nicht (d.h. dort muss ich nicht so exzessiv auf die Laufzeiteffizient achten). Es stimmt auch das ich von Laufzeitoptimierungen, aus oben genannten Gründen, relativ wenig Erfahrung haben und ich eben desswegen hier Frage. Der Grund warum ich jedoch auf deinen Post antworte ist, dass du mich deinem Post, speziell dem Wortlaut im ersten Absatz zufolge, als irgendeinen Skript-Kiddie hinstellst der gerade sein erstes Hello-Word-Programm erfolgreich aus dem Tutorial abgeschrieben hat. Falls ich das falsch interpretiert habe, dann tut es mir Leid. Ich habe nun seit 11 Jahren mit programmieren zu tun (5 Jahre Schule und 6 Jahre Praxiserfahrung). (Nur um das Thema entgültig aus der Welt zu schaffen.) Ich will jedoch jetzt auf keinen Fall ein ewiges herumgeflame provozieren, ich wollte nur zu deinem Post Stellung nehmen.
    Nun aber zurück zum Algorithmus den du auch angesprochen hast. Es ist auf keinen Fall irgendetwas bahnbrechendes neues, wie du ja bereits vermutet hast, sondern im Prinzip ist ist er sogar relativ simpel und primitiv, denn wenn er das wäre wäre ich wahrscheinlich bereits steinreich. Wie gesagt, ich habe es bereits oft gesagt und sage es gerne nocheinmal, der Grund warum der Kompressionsgrad relativ hoch ist ist, dass das Programm einfach exakt auf unsere Bedürfnisse zugeschnitten ist. Das Problem an anderen Kompressionsalgortihmen (z.B.: von zib) ist, dass diese alles komprimieren können müssen (z.B.: Textdatein, Bilder, Filme,...). Natürlich bleibt durch diese Vielseitigkeit eine Menge Effizienz auf der Strecke. Eigentlich wollte ich garnichts über den Kompressionsgrad sagen, da ich vermutet habe, dass das ausarten könnte (z.B.: Dann beweis das mal,...). Der Grund warum ich es trotzdem gesagt haben ist, dass mit Badestrand danach gefragt hat.
    So das wollte ich nur schnell geklärt haben, ich hoffe ich habe dich dadurch nicht verletzt oder persönlich angegriffe. Ich bin nicht hier um zu prahlen, sonder nur um mir ein paar gute Tipps abzuholen. Ich bedanke mich aber trotzdem für den Tipp.

    mfg



  • std::string verwendet i.A. dynamische Speicheranforderungen (new), um Speicher für den String zu bekommen. MSVC hat AFAIK einen 16 Byte Puffer in std::string eingebaut, d.h. Strings die kleiner als 16 Byte sind sind "schnell". Für alles grössere wird der Speicher vom Heap geholt.

    Der String liegt dabei schon "linear" im Speicher wie bei einem Array, und das ist auch nicht das Problem. Wenn du Strings im kritischen Code (die Teile die verdammt oft durchlaufen werden) nur ausliest dann ist das OK und du kannst ruhigen gewissens std::string verwenden.

    Die Schwierigkeit bei C++ ist u.A. zu wissen was bestimmte Klassen oder Funktionen intern tun.

    Ein Beispiel: nimm eine std::list und füge 1 Mio. Elemente ein, und dann probier das gleiche mit einem std::vector. Die Version mit std::vector wird um Längen schneller sein, weil std::vector nicht 1 Mio. Speicheranforderungen macht (wie std::list), sondern eher < 100 (MSVC: 30-40 wenn ich richtig gerechnet habe). Dafür müssen die Elemente auch jedesmal kopiert werden, was aber im Normalfall immer noch VIEL schneller ist als den (langsamen) Heap zu bemühen.

    Oder: sagen wir du hast eine Schleife die Zeilen aus einem File in einen Puffer liest, und weisst nicht wie lange die Zeilen werden können. Also kannst du keinen ausreichend grossen Puffer vor-anfordern. Wenn du nun z.B. einen std::vector<char> verwendest um den Inhalt einer Zeile zwischenzuspeichern macht es einen u.U. deutlichen Unterschied ob du den vector in der Schleife anlegst oder ausserhalb. In der Schleife wird er bei jedem Durchlauf zerstört und neu angelegt. Dabei wird der Speicher freigegeben und der neue vector muss danach neu "wachsen", also neu Speicher anfordern. Ausserhalb der Schleife wird der vector anwachsen und irgendwann ist er gross genug. Der Speicher wird normalerweise nicht freigegeben bis die Funktion fertig gelaufen ist, selbst wenn du den vector mit .clear() "leer" machst (MSVC hält es so, und ich glaube der Standard gibt es auch so vor).



  • Possessed schrieb:

    So das wollte ich nur schnell geklärt haben, ich hoffe ich habe dich dadurch nicht verletzt oder persönlich angegriffe. Ich bin nicht hier um zu prahlen, sonder nur um mir ein paar gute Tipps abzuholen. Ich bedanke mich aber trotzdem für den Tipp.

    deine andeutungen haben sich erstmal interessant angehört und ich wollte nur mal sagen, auf welchen anspruch des algorithmus das level deiner fragen hindeutet. du solltest dir vielleicht die äußerungen irgendwelcher anonymer spacken in webforen nicht so zu herzen nehmen.

    nenn doch mal ein paar details zu deinem alogrithmus, denn es hört sich nach wie vor interessant an.



  • Hast du denn mal mit nem Profiler geprüft wo denn die Performance-Probleme von deinem Programm wirklich liegen. Ansonsten ist das hier ne mehr oder weniger
    philosophische Diskussion, die dir bei deinem konkreten Problem nicht wirklich weiterhilft.


Anmelden zum Antworten