stackobjekte und new

volkard

Pria schrieb:

ipsec schrieb:

Es handelt sich hier bestenfalls um ein paar Takte ( vector und new[] sollten quasi identisch sein)

Laut meiner Messung mit QueryPerformanceCounter ist .push_back um etwa 1/3 langsamer als eine Pointerzuweisung wenn ich keine geeignete Listengröße vorgebe, da ich diese aber kenne, da diese statisch pro durchgang bekannt ist kann ich genausogut ein * Array nehmen und mit ++ durchiterieren.

Bitte nur im Release-Modus mit allen Optimierungen messen, und nur mit ausgeschalteten Bereichsüberprüfungen.

Pria schrieb:

ipsec schrieb:

Es handelt sich hier bestenfalls um ein paar Takte ( vector und new[] sollten quasi identisch sein)

Laut meiner Messung mit QueryPerformanceCounter ist .push_back um etwa 1/3 langsamer als eine Pointerzuweisung wenn ich keine geeignete Listengröße vorgebe, da ich diese aber kenne, da diese statisch pro durchgang bekannt ist kann ich genausogut ein * Array nehmen und mit ++ durchiterieren.

Du verwendest ihn nur falsch. vector::push_back entspricht in etwa:

void push_back(T const& elem)
{
    if(is_storage_full())
    {
         get_larger_storage();
         copy_everything_to_new_storage();
         destroy_old_storage();
    }

    insert_at_end(elem);
}

Was du vermutlich möchtest ist

a.)

vector<unsigned> v;
v.reserve(N);
for(unsigned i = 0; i < N; ++i)
    v.push_back(i);

b.)

vector<unsigned> v;
v.resize(N);
for(unsigned i = 0; i < N; ++i)
    v[i] = i;

asc

Pria schrieb:

Nein! Ich brauch die Geschwindigkeit die mir ein vector oder list nicht bieten kann.

Wie schon von mehreren Geschrieben ist deine Aussage Unsinn. Die C++ Standardbibliothek ist in erster Linie auf Geschwindigkeit ausgelegt, man sollte aber auch wissen, wie man diese einsetzt.

Wenn man sie falsch einsetzt (oder gar im Debug testet), kommt natürlich Unsinn raus. In deinem Fall ist deine Variante sogar höchst gefährlich.

1. Verwendest du Zeiger/new/delete ohne zu wissen was du tust
2. Würde in deiner Variante ein Destruktor alleine auch nicht reichen (Du müsstest entweder noch den Kopierkonstruktor/Zuweisungsoperator mitliefern, oder selbige unterbinden)...

Pria schrieb:

Sone schrieb:

char für die Anzahl?

Ist nie höher als 255 daher speichertechnisch besser

Einerseits redest du von Performance, anderseits möchtest du auf Speicher hin optimieren?

Nathan

asc schrieb:

Pria schrieb:

Sone schrieb:

char für die Anzahl?

Ist nie höher als 255 daher speichertechnisch besser

Einerseits redest du von Performance, anderseits möchtest du auf Speicher hin optimieren?

Beides geht nämlich nicht.
Entweder du berechnest die Länge eines Strings anhand einer Schleife bei jedem length() Aufruf oder du speicherst sie als Member. Die eine Version ist speicherfreundlich, die andere schnell.

Wozu brauchst du die Optimierung? Optimiere erst, wenn alles fertig ist und dein Programm zu langsam ist. Und dann nur die Parts, die am meisten etwas ausmachen und nicht alles (80/20-Regel).

dd++ 0

wenn es eine Number Cruncher Software ist, muß man schon ganz am Anfang 100% optimieren, siehe z.B. hier:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

dd++ schrieb:

wenn es eine Number Cruncher Software ist, muß man schon ganz am Anfang 100% optimieren

Aber ganz sicher nicht mit operator new[] . Der ist saulahm.

Ethon

Jap. POD-Arrays legt man auch in C++ lieber mit malloc an wenn jeder Furz an Performance zählt da malloc keine Konstruktoren aufruft.

Nexus

Seit wann ruft new[] bei POD-Typen (nach C++98) Konstruktoren auf?

Ausserdem kann man, wenn man Konstruktoren definiert, auch eine Uninitialized-Version anbieten.

SeppJ

Ethon schrieb:

Jap. POD-Arrays legt man auch in C++ lieber mit malloc an wenn jeder Furz an Performance zählt da malloc keine Konstruktoren aufruft.

Ähh, new auch nicht, wenn's nicht nötig ist. Und wenn's doch nötig ist, dann ist es nötig und man muss new nehmen.

Wie sollte new denn auch bei POD einen Konstruktor aufrufen? Es gibt schließlich keinen.

P.S.: Geht es nur mir so oder hat noch jemand anderes das Gefühl, dass der TE sich hier selber das Leben schwer macht? Widersprüchliche Optimierungsstrategien, Messungen offensichtlich im Debugmodus durchgeführt, mythische Ansichten über die Standardbibliothek. Klingt alles so, als habe jemand mal davon gehört, dass Optimierung ganz was tolles ist, ein paar Tricks gesehen, aber nicht verstanden hat.

Nexus

SeppJ schrieb:

P.S.: Geht es nur mir so oder hat noch jemand anderes das Gefühl, dass der TE sich hier selber das Leben schwer macht? Widersprüchliche Optimierungsstrategien, Messungen offensichtlich im Debugmodus durchgeführt, mythische Ansichten über die Standardbibliothek. Klingt alles so, als habe jemand mal davon gehört, dass Optimierung ganz was tolles ist, ein paar Tricks gesehen, aber nicht verstanden hat.

Ja, "Ich brauch die Geschwindigkeit die mir ein vector oder list nicht bieten kann" sollte als erstes Alarmsignal ernst genommen werden.

Ich hoffe, wir können Pria noch auf die gute Seite bringen.