Gibt es einen Algorithmus in der STL, der.....

aber es muss überprüfen, ob Bedarf da ist.
Kann man das durch den [] operator einsparen?

Blue-Tiger

paddy@work schrieb:

aber es muss überprüfen, ob Bedarf da ist.
Kann man das durch den [] operator einsparen?

bist du sicher dass du grad an der richtigen Stelle optimierst? o_0

ja, denn es muss wirklich alles optimiert werden :-(((

Ich habe eine Vorgabe bekommen, da muss ich selbst sowas berücksichtigen....

Warum liest du nicht sofort in den vector ein? Oder benutz memcpy.

Knuddlbaer

Wie sieht denn die vorgabe im Detail aus ?
i.d.R. ist die STL doch schon optimiert. Man kann dann nurnoch für den Spezialfall optimieren und den sucht man sich meist mit einem Profiler ?!

finix

Hast du schon mal

// _Buffer & _Data sind ganz, ganz schlecht gewaehlte Bezeichner
_buffer.insert(_buffer.end(), _data, _data + numberOfBytes);

statt push_back versucht?

Und was ist mit deinem reserve - welchen Sinn soll das haben, und wieso genau 65536 hardcoded?

volkard

finix schrieb:

Und was ist mit deinem reserve - welchen Sinn soll das haben, und wieso genau 65536 hardcoded?

das drückt die laufzeit bei wiederholten aufrufen von O(n) auf O(n^2).

Knuddlbaer

eventuell soll das reserve verhindern, das ständig neuer speicher alloziiert werden muss.

Denn wenn die Elemente zu klein sind muss neuer speicher organisiert werden und alle Elemente müssen umkopiert werden (was z.B. auch iteratoren zerstört).

ich habe die passage aus dem kontext heraus kopiert, so dass die Namen echt nicht gut sind, allerdings machen sie im zusammenhang mit dem rest der methode mehr sinn.

Die 64KB sind hardgecoded, da ich durch regelmäßiges testen, zu dem Entschluss gekommen bin, dass das Verhältnis zwischen Speichergröße und der Anzahl der reserve aufrufe vernünftig ist. ich sollte mir nichts desto trotz eine Konstante dafür machen.

Was macht den Unterschied zwischen insert und push_back Schleife?

volkard

muß es denn ein vector sein? ich finde, hier riecht's nach queue.

leider ja, wird mir vom Interface vorgeschrieben....

finix

volkard schrieb:

finix schrieb:

Und was ist mit deinem reserve - welchen Sinn soll das haben, und wieso genau 65536 hardcoded?

das drückt die laufzeit bei wiederholten aufrufen von O(n) auf O(n^2), macht also fatal lahm. normales zwischenergebnis beim explorativen optimieren.

Hehe, ja. Effektiver Weg um das Storagemanagement von std::vector zu sabotieren.
Das reserve wäre ohnehin nur sinnvoll für sizeof(Data) >> buffer.capacity().

Also ich muss die Werte in einen vector von unsigned char (Also 1 byte) anbieten. Die daten kommen in ca. 50 - 200 leider aber selten auch in 4096 byte großen strömen bei mir an. Allerdings kommen sehr viele von diesen kleinen Datenmengen an.

wenn ich nicht mit reserve arbeiten würde, müsste doch für jedes byte immer wieder neu speicher reserviert werden (im push_back).

Das möchte ich verhindern, da es doch langsamer ist, 65536 mal 1 Byte speicher zu holen, als einmal 64 KB, oder sehe ich das falsch?

finix

paddy@work schrieb:

ich habe die passage aus dem kontext heraus kopiert, so dass die Namen echt nicht gut sind, allerdings machen sie im zusammenhang mit dem rest der methode mehr sinn.

Vielleicht ist dir aufgefallen dass ich in meinem Snippet lediglich von uppercase auf lowercase übergegangen bin:

Bezeichner die
mit Understriche + Großbuchstaben beginnen
zwei aufeinander folgende Unterstriche enthalten
im globalen Namensraum liegen und mit Unterstrich beginnen
sind reserviert. Google wird dir noch ein paar mehr Ausnahmen & konkrete Bezeichner liefern können, aber obiges ist eine nette Faustregel.

volkard

paddy@work schrieb:

Die 64KB sind hardgecoded, da ich durch regelmäßiges testen, zu dem Entschluss gekommen bin, dass das Verhältnis zwischen Speichergröße und der Anzahl der reserve aufrufe vernünftig ist.

war es nicht immer so, daß physikalischer speicher erst allokiert wird, wenn die mit new virtuell allokierten speicherseiten auch angefasst werden, weshalb int* pi=new int[1000000000]; auch so schnell geht und erst beim beschreiben geht die party los?
mal angenommen, das wäre so, wäre dann das reserven nicht unfug und insert bzw pushback einfach nur toll?

__HIRSCH_H__

Jester schrieb:

Auch beim Kopieren solltest Du mittels reserve für ausreichenden Platz sorgen. Ansonsten läßt sich da vermutlich nicht so viel machen. Das Kopieren kannste auch von std::copy erledigen lassen. Schneller ist das aber auch nicht.

Doch, der std::copy algorithmus ist spezialisiert für einige POD Typen und verwendet intern memmove bzw. memcpy.
Zumindest bei der stdc++ vom g++ iss das so.

LordJaxom

paddy@work schrieb:

wenn ich nicht mit reserve arbeiten würde, müsste doch für jedes byte immer wieder neu speicher reserviert werden (im push_back).

Das möchte ich verhindern, da es doch langsamer ist, 65536 mal 1 Byte speicher zu holen, als einmal 64 KB, oder sehe ich das falsch?

Grundsätzlich siehst Du das nicht falsch, aber "so doof" sich immer nur ein Byte zu holen wird kein Vector dieser Welt sein

volkard

paddy@work schrieb:

Das möchte ich verhindern, da es doch langsamer ist, 65536 mal 1 Byte speicher zu holen, als einmal 64 KB, oder sehe ich das falsch?

ganz dicker hund das.
push_back verdopplet immer den speicher, wenn der alte alle ist. das führt zu amortisierten kopierkosten von O(1) pro push. (wegen 1+2+4+8+16+32+...+2¹⁶⁼⁼²17-1, also bei startgröße 1 und 16 mio einfügungen gäbe es nur 32 mio kopierungen und vor allem nur 32 aufrufe von new/delete).
mit jedem fixen reserve haste O(n).
wenn du doch reserve nimmst, um copy nehmen zu können (würde ich vermutlich tun), dann geh auch so vor (würde ich auch tun).
oder wenigstens

if( (capacity - size) < 4096) //diese bedingung ist unsauber
 { 
      _Buffer.reserve(capacity+max(65536,capacity/8)); //nicht mein geschmack
 }

std::vector<unsigned char> data(4096);
recv(s, &data[0], data.size(), 0);

also entweder reserve und copy, oder nur push_back schleife?

und wie kommst du auf die /8 ???