Fehler, Irrtümer, Fragen - Seite 2668

[fxsaber]

Sergey Dzyublik:

Das Problem ist, dass, wenn ich Speicher reservieren und erstellen Array-Elemente ein zu einer Zeit, es dauert viele Male länger als nur erstellen sie alle auf einmal.

Das ist mir im Code nicht aufgefallen. Erklärt dann, wie es nur eine wenn ausgelöst, wo, wenn die Größe nicht geändert hat, beenden.

[Sergey Dzyublik]

fxsaber:

Das ist mir im Code nicht aufgefallen. Erklärt dann, wie es nur eine wenn ausgelöst, wo, wenn die Größe nicht geändert hat, beenden.

Erläuterung des obigen Codes#2666

test1, erstellt alle Elemente auf einmal beim ersten Aufruf, die restlichen Aufrufe von ArrayResize gehen "ins Leere".
Die Gesamtanzahl der ArrayResize-Aufrufe == array_size:

      T class_array[];
      for(int i = 1; i <= array_size; i++){
         ArrayResize(class_array, array_size);
      }

test2, erzeugt ein Element und reserviert Platz für ein weiteres array_size-1 Element, die verbleibenden Aufrufe von ArrayResize erzeugen +1 Element im Array aus dem zuvor reservierten Speicher.
Die Gesamtzahl der Aufrufe von ArrayResize == array_size:

      T class_array[];
      ArrayResize(class_array, 1, array_size - 1);
      for(int i = 2; i <= array_size; i++){
         ArrayResize(class_array, i);
      }

* Es gab einen Fehler im ursprünglichen Code (+- ein Element Unterschied). Der Code wurde aktualisiert.
Es bleibt die Frage: Warum ist der Algorithmus test2 bei Strukturen 7-mal langsamer als test1 und bei Klassen und int 2-mal langsamer?

[Alain Verleyen]

Sergey Dzyublik :

Auf meiner Seite war der Vergleich so, wie er sein sollte.
Ich weiß, wie viele Elemente in das Array eingefügt werden sollen, und anstatt sie alle auf einmal zu erstellen, reserviere ich Speicher für die noch nicht erstellten Elemente.
Das Problem ist, wenn ich Speicher reserviere und Array-Elemente eines nach dem anderen erstelle, dauert es um ein Vielfaches länger als wenn ich sie alle auf einmal erstelle.
Bei Strukturen ist es also 7 Mal langsamer.
Und bei den Datentypen class und int ist es doppelt so langsam.

Dies ist ein sehr großer Unterschied, den die Entwickler meines Erachtens beseitigen können, wenn sie dies wünschen.

OK, in diesem Fall stimme ich zu, dass es nur niedrigere Gemeinkosten geben sollte.

Meiner Meinung nach liegt das Problem jedoch eher in der Art und Weise, wie Sie vergleichen. Die Schleife in test1 wird wahrscheinlich vom Compiler optimiert und entfernt, und vielleicht sogar noch weiter:

 for ( ulong ii= 0 ;ii<count&&! _StopFlag ;ii++)

Probieren Sie den Profiler aus, und Sie werden nur einen kleinen Unterschied feststellen.

[Alain Verleyen]

Keine Compiler-Optimierung mit dem Profiler.

[fxsaber]

Sergey Dzyublik:

Es bleibt die Frage: Warum ist test2 bei Strukturen um den Faktor 7 und bei Klassen und int um den Faktor 2 langsamer als test1?

Standard-Konstrukteure.

[Sergey Dzyublik]

Alain Verleyen:

Die Schleife in test1 wurde wahrscheinlich vom Compiler optimiert und entfernt

Wenn Sie den obigen Code#2666 im Debug-Modus ausführen, werden Sie ähnliche Ergebnisse wie zuvor erhalten, da die Verzögerung in der Arbeit der ArrayResize-Funktion und nicht in der Optimierung des Anwendercodes liegt.
Der Debug-Modus wird ohne jegliche Optimierungen ausgeführt: Was im Code steht, wird ausgeführt, und was ausgeführt wird, sind nur nop-Typen für Benutzer, die Haltepunkte zwischen Anweisungen einfügen.

[Aleksei Skrypnev]

Ich erhalte keine SMS mit der Bestätigung der Eröffnung eines Demokontos per SMS. Weitere Details hier.

https://www.mql5.com/ru/forum/334179#comment_1529250

[Alain Verleyen]

Sergey Dzyublik :

Wenn Sie den obigen Code #2666 im Debug-Modus ausführen, werden Sie ähnliche Ergebnisse wie zuvor erhalten, da die Verzögerung in der Arbeit der ArrayResize-Funktion und nicht in der Optimierung des Anwendercodes liegt.
Der Debug-Modus wird ohne jegliche Optimierungen ausgeführt: Was im Code steht, wird ausgeführt, und was ausgeführt wird, sind nur nop-Typen für Benutzer, die Haltepunkte zwischen Anweisungen einfügen.

Wie in Beitrag #26674 gezeigt, keine Probleme mit ArrayResize (), sondern nur mit Vergleichstest. Es sei denn, ich habe etwas übersehen.

[Sergey Dzyublik]

Alain Verleyen:
Wie in Beitrag #26674 gezeigt, gibt es kein Problem mit ArrayResize (), sondern nur mit dem Vergleichstest. Es sei denn, ich habe etwas übersehen.

Das Problem wurde in einem realen Projekt bei der Suche nach einem Engpass für den Algorithmus vector<T>::push_back entdeckt.
Das Problem erscheint als Teil der langsamen Ausführung von ArrayResize in Anwesenheit von reserviertem Speicher sowohl in Release- als auch in Debug-Kompilierungen.

Sie behaupten, alles sei in Ordnung, weil die Profilerstellung nichts ergeben habe.
Die erzielten Ergebnisse stören niemanden.
Das Fehlen offensichtlicher Probleme bei der Profilerstellung bedeutet jedoch nicht, dass sie in den Release- und Debug-Kompilierungen, die von 100 % der Benutzer verwendet werden, nicht auftreten.

[Alain Verleyen]

Sergey Dzyublik :

Das Problem wurde im realen Projekt bei der Suche nach einem Engpass für den vector<T>::push_back Algorithmus entdeckt.
Das Problem erscheint als Teil der langsamen Ausführung von ArrayResize in Anwesenheit von reserviertem Speicher sowohl in Release- als auch in Debug-Kompilierungen.

Sie behaupten, alles sei in Ordnung, weil die Profilerstellung nichts ergeben habe.
Die erzielten Ergebnisse stören niemanden.
Das Fehlen offensichtlicher Probleme bei der Profilerstellung bedeutet jedoch nicht, dass sie in den Release- und Debug-Kompilierungen, die von 100 % der Benutzer verwendet werden, nicht auftreten.

Ich kann nur über den von Ihnen bereitgestellten Testcode sprechen.

Auf jeden Fall wollen wir sehen, was die Entwickler zu sagen haben. Vielleicht.