Errori, bug, domande - pagina 2668

[fxsaber]

Sergey Dzyublik:

Il problema è che se riservo la memoria e creo gli elementi dell'array uno alla volta, ci vuole molto più tempo che crearli tutti insieme.

Non ho notato questo nel codice. Spiega allora che c'è solo un if innescato, dove se la dimensione non è cambiata, esce.

[Sergey Dzyublik]

fxsaber:

Non ho notato questo nel codice. Spiega allora che c'è solo un if innescato, dove se la dimensione non è cambiata, esce.

Spiegazione del suddetto codice#2666

test1, crea tutti gli elementi in una volta sola alla prima chiamata, le restanti chiamate di ArrayResize vanno in "idle".
Il numero totale di chiamate ArrayResize == array_size:

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

test2, crea un elemento e riserva spazio per un altro elemento array_size-1, le restanti chiamate ad ArrayResize vanno a creare +1 elemento nell'array dalla memoria precedentemente riservata.
Il numero totale di chiamate a 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);
      }

* c'era un errore nel codice originale (+- un elemento di differenza). Il codice è stato aggiornato.
La domanda rimane: perché l'algoritmo test2 è 7 volte più lento di test1 per le strutture e 2 volte più lento per le classi e gli int?

[Alain Verleyen]

Sergey Dzyublik :

Dalla mia parte il confronto era quello che doveva essere.
So quanti elementi saranno messi nell'array e, invece di crearli tutti insieme, riservo la memoria per quelli non creati.
Il problema è che se riservo la memoria e creo gli elementi dell'array uno per uno, ci vuole molto più tempo che crearli tutti insieme.
Quindi per le strutture è 7 volte più lento.
Ed è due volte più lento per i tipi di dati class e int.

Questa è una differenza molto grande, che penso che gli sviluppatori possano eliminare se lo desiderano.

OK in questo caso, sono d'accordo che ci dovrebbero essere solo spese generali più basse.

Ma, secondo me, il problema è più il modo in cui si fa il confronto. Il ciclo nel test1 è probabilmente ottimizzato e rimosso dal compilatore, e forse anche il prossimo:

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

Provate il profiler e vedrete solo una piccola differenza.

[Alain Verleyen]

Nessuna ottimizzazione del compilatore con il profiler.

[fxsaber]

Sergey Dzyublik:

La domanda rimane: perché test2 è più lento di test1 per le strutture di un fattore 7, e di un fattore 2 per le classi e gli int?

Costruttori predefiniti.

[Sergey Dzyublik]

Alain Verleyen:

Il ciclo nel test1 è probabilmente ottimizzato e rimosso dal compilatore

Se eseguite il codice#2666 di cui sopra in modalità Debug, vedrete risultati simili a quelli ottenuti in precedenza, poiché i rallentamenti sono causati dal lavoro della funzione ArrayResize e non dall'ottimizzazione del codice utente.
La modalità di debug viene eseguita senza alcuna ottimizzazione: ciò che è scritto nel codice viene eseguito e ciò che viene eseguito è solo nop-type per i breakpoint utente sono inseriti tra le istruzioni.

[Aleksei Skrypnev]

Non ricevo SMS sul nuovo servizio che conferma l'apertura di un conto demo via SMS. maggiori dettagli qui.

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

[Alain Verleyen]

Sergey Dzyublik :

Se eseguite il codice #2666 di cui sopra in modalità Debug, vedrete risultati simili a quelli ottenuti in precedenza, poiché il ritardo è nel lavoro della funzione ArrayResize e non nell'ottimizzazione del codice utente.
La modalità di debug viene eseguita senza alcuna ottimizzazione: ciò che è scritto nel codice viene eseguito e ciò che viene eseguito è solo nop-type per i breakpoint utente sono inseriti tra le istruzioni.

Come mostrato nel post #26674, nessun problema con ArrayResize (), ma solo con il test comparativo. A meno che non mi sia perso qualcosa.

[Sergey Dzyublik]

Alain Verleyen:
Come mostrato nel post #26674, non c'è nessun problema con ArrayResize (), ma solo con il test di confronto. A meno che non mi sia perso qualcosa.

Il problema viene rilevato all'interno di un progetto reale quando si cerca il collo di bottiglia per l'algoritmo vector<T>::push_back.
Il problema appare come parte della lenta esecuzione di ArrayResize in presenza di memoria riservata in entrambe le compilazioni Release e Debug.

Lei sostiene che tutto è a posto perché il profiling non ha rilevato nulla.
Nessuno si preoccupa dei risultati ottenuti.
Tuttavia, l'assenza di problemi evidenti durante la profilazione non li annulla nelle compilazioni Release e Debug che sono utilizzate dal 100% degli utenti.

[Alain Verleyen]

Sergey Dzyublik :

Il problema è stato rilevato all'interno di un progetto reale durante la ricerca del collo di bottiglia per l'algoritmo vector<T>::push_back.
Il problema appare come parte della lenta esecuzione di ArrayResize in presenza di memoria riservata in entrambe le compilazioni Release e Debug.

Lei sostiene che tutto è a posto perché il profiling non ha rilevato nulla.
Nessuno si preoccupa dei risultati ottenuti.
Tuttavia, l'assenza di problemi evidenti durante la profilazione non li annulla nelle compilazioni Release e Debug che sono utilizzate dal 100% degli utenti.

Posso solo parlare del codice di prova che hai fornito.

In ogni caso, vediamo cosa hanno da dire gli sviluppatori. Forse.