Performance + STL



  • Hallo,

    Ich schreib eine Anwendung, die doch recht zeitkritisch ist ... (Ueberwachung von Nachrichten auf einem physikalischen Bus ... ).
    Zum Speichern meiner Daten (Temporaere und statische) verwend ich STL-Containerklassen (momentasn noch die M$ Implementierung der STL) ... bevorzugt Maps und Sets ...

    Nun meine Frage ... ich hab oefters kleinere Listen (ca 20... 100 eintraege) temporaer abzuspeichern, deren lebenszeit kurz ist. Zugriffe auf diese Listen muessen dementsprechend auch schnell sein (ich brauch oft das erste, das letzte und an und ab nen bestimmtes Element aus der Liste(mit find) )....
    Meine Kentnisse ueber Profiler sind ned so berauschend ... aber ich denke einen grossteil der Rechenzeit verheize ich beim Instanziieren der STL-Klasse an sich ... Wie verhaelt sich das ganze nun, wenn ich statt der vielen Listen (sets) eine Grosse Liste nehme ... dafuer aber den MehrAufwand beim Suchen in Kauf nehme ...

    Hat da wer schon irgendwelche Erfahrungen ??? Gibts da irgendwo Literatur zu ???

    Ciao...



  • Meine Kentnisse ueber Profiler sind ned so berauschend

    Dann sollte einer deiner ersten Schritte sein, dies zu ändern.

    aber ich denke einen grossteil der Rechenzeit verheize ich beim Instanziieren der STL-Klasse an sich

    Glaub mir, in 95% der Fälle denkt man was Performance-Flaschenhälse angeht falsch. Nicht raten, denken, glauben sondern messen.

    bevorzugt Maps und Sets ...

    Mach dir klar wie du maps einsetzt. Die meisten die eine STL-Map einsetzen, brauchen eigentlich besser eine Hash-Map.
    Wenn die Verwendung in die Richtung
    1. viel einfügen
    2. viel abfragen
    3. löschen
    geht, versuch mal die Map durch einen sortierten Vektor zu ersetzen.

    Zugriffe auf diese Listen muessen dementsprechend auch schnell sein (ich brauch oft das erste, das letzte und an und ab nen bestimmtes Element aus der Liste(mit find) )....

    Das hört sich nicht nach Liste an. Wie sehen deine Daten aus? Was ist wichtig? Brauchst du die Commit-or-Rollback-Eigenschaften einer Liste? Wäre eine deque oder ein vector nicht besser geeignet? Macht es sinn die Daten zu sortieren?

    Meiner Meinung nach lässt sich aber ohne deine Daten und Zugriffsszenarien zu kennen, kaum eine wirklich fundierte Aussage treffen.

    Gibts da irgendwo Literatur zu ???

    Es gibt tonnenweise Literatur zu Datenstrukturen und ihrem effizienten Einsatz. Konkret zur STL empfehle ich Scott Meyers': "Effective STL" und N. Josuttis': "The C++ Standard Library".



  • Zu meinen Daten ...

    Es sind eigentlich hauptsaechlist 2 Typen die ich speichere ....
    - Zeitliche Daten (Telegramme) , die haben nen Zeitstempel (64 bit Integer) nach dem werden sie Sortiert ... deshalb Set ... Wenn ich sage erstes und letztes Element ... dann mein ich das mit den niedrigsten oder hoechsten Zeitstempel ....

    - Zuordnungen / gruppierungen .... Sind hauptsaechlist sachen, wo ich Zeitliche Daten (telegramme) einer Kategorie zuordnete (Bus, ID aufn bus), und ich viel Lookups auf diese Kategorien durchfuehre.

    Um eine Aussage ueber die Telegramme machen zu koennen, brauch ich eine Zuordnung von mehreren Telegrammen eines Types(Reaktionen auf ein bestimmtes Telegramm ), zu einem Telegram (Trigger einer gewissen Funktion) eines anderen Types.

    Wenn ich die Telegramme aus einer Konserve (Mitschnitt des Busverkehrs) bekomme, ists kein Problem. Aber Ich kann die Telegramme auch direkt vom Bus bekommen, mitels Schnittstellenkarte. Diese Karte generiert den Zeitstempel fuer die Telegramme selbst ... also ist das kein problem.
    Das Problem ist aber die Rechenleistung an sich ... mit fast konstanten 1200 Telegrammen/s ist der Verkehr halt ned wenig 🙂 Und wenn ich die Daten langsamer verarbeite, als wie sie eintreffen, bring ich das System zum stehen, und verliere Telegramme, weil die Schnittstellenkarte und ihr Treiber keine Rechenleistung mehr bekommt. ausserdem steht das system dann, fuer ne weile 🙂

    Meine Frage ist nun ... was Performance-maessig besser ist
    - FUer die Triggertelegramme jedes mal eine eigene Liste(Set) anlegen, fuer die zugehoerigen telegramme, dafuer aber recht einfach und schnell zugriff auf die Telegramme zu haben. Es wird aber fuer jedes dieses Triggertelegram eine neue Liste (set) angelegt.

    - eine allgemeine Liste fuer alle Zuordnungen .... die Liste wird aber dann gross, und das Suchen wird komlizierter, verbraucht mehr ressourcen .... wobei ich auch noch keine Ahnung habe, wie man dass effektiv gestalten koennte. Ich brauchte eine Sache ala std::map<Telegramm, Triggertelegramm> wo ich aber sehr schnell auf das 1. oder letzte Telegramm vom Triggertelegramm X zugreifen muesste .... in ner map kann man leider nicht nach dem 2. Wert effektiv suchen.
    Das aufsplitten in eine komplizierte Struktur wuerde aber wieder in ein dynamisches erzeugen von Listen enden, sobald ein Triggertelegram eintrifft.

    Im moment hab ich version 1 am laufen ... durch auskommentieren kritischer Abschnitte hab ich rausbekommen, das das einfuegen,loeschen, und lookups in den tempraerer Zuprdnungslisten kein Thema ist .... Aber nen grossteil der RechenZeit verheize ich beim erzeugen der Liste fuer das Triggertelegramm ... und suche nun nach alternativen ...

    Ich hoffe nun versteht man das Problem besser ....

    Ciao ....



  • Das klingt jetzt nicht allzu hilfreich, aber Du wirst einfach nicht darum herumkommen: Lern mit einem Profiler umzugehen und miss aus was Dir die beste Performance bringt!



  • Ok, dann schaetz ich, werd ich ned drumherum kommen .... :p
    Naja, frueher oder spaeter muss ich mich da he durchknien, leider hab ich im Moment auf Grund des Zeitplanes, eigentlich ned die Zeit zu ... eigentlich nen Widerspruch 🙂

    Wir haben hier den Intelprofiler, den VTune. Gibts da, wenn moeglich deutschsprachige(weil das kann ich schneller lesen 🙂 ), Literatur zu ... die Online Anleitung selbst wirkt etwas .... ueberladen ...

    Danke ...

    Ciao,



  • zum vtune gibts ein flash, dort wird alles schnell erklärt
    sollte für den einstieg reichen



  • Ok, danke, ich werd es mal in Angriff nehmen 🙂

    Ciao ...


Anmelden zum Antworten