[C++] Velocità di elaborazione immagini con diverse strutture dati

[il_dordollano]

Devo elaborare un file immagine .pixmap e vorrei anche utilizzare immagini medio grandi. Il programma sarà più veloce se uso array di char, se uso stringhe con le relative funzioni oppure è uguale?
A rigor di logica, essendo le stringhe degli array di char, dovrebbe essere identico il tempo, ma vorrei una conferma.

[RooccoXXI]

Originariamente inviato da il_dordollano
Devo elaborare un file immagine .pixmap e vorrei anche utilizzare immagini medio grandi. Il programma sarà più veloce se uso array di char, se uso stringhe con le relative funzioni oppure è uguale?
A rigor di logica, essendo le stringhe degli array di char, dovrebbe essere identico il tempo, ma vorrei una conferma.

Premetto che non sono un programmatore esperto, ma a mio avviso se cerchi l'efficienza la cosa migliore é utilizzare le funzioni della libreria standard. A naso ti direi di utilizzare un std::vector e di lavorarci sopra con gli iteratori e gli algoritmi della libreria standard.

[Scara95]

Se cerchi la pura velocità ti conviene un array di byte (o unsigned char) da te gestito, però perdi molto in mantenibilità e gestibilità del codice.
Ti conviene conservare quest'ultima piuttosto di guadagnare un po' di velocità anche perchè rischi di trovarti con un codice ingestibile e pieno di bug.

[linoma]

Se il tuo problema è la velocita' e lavori su sistemi multiprocessore sfrutta quest'ultima a scapito dell'array di bytes.

[il_dordollano]

Ti conviene conservare quest'ultima piuttosto di guadagnare un po' di velocità anche perchè rischi di trovarti con un codice ingestibile e pieno di bug.

Se il tuo problema è la velocita' e lavori su sistemi multiprocessore sfrutta quest'ultima a scapito dell'array di bytes.

Vi rigrazio, ma mi state dicendo: "L'array di bytes è veloce ma non usarlo". Io mi trovo da punto a capo, non so nemmeno usare gli array di bytes.

è più o meno veloce operare con string in confronto a un array di char?

[Scara95]

Un array di char (più precisamente unsigned char, ma lo è di default) è equivalente ad un array di byte ed è più veloce di una string, ma introduce molte più complicazioni che possono intrudurre bug e far si che il codice, se mal strutturato, risulti più lento di uno con un più alto livello di astrazioni.
A parte che sarebbe più logico l'uso di vector che di string, o comunque di altre strutture...
String è per l'elaborazione di stringhe di testo...

In sostanza: in assoluto un array di char è più veloce ma in realtà la scelta va valutata più cautamente.

Altra possibile soluzione è la parallelizzazione, come ti è stato suggerito, la quale però introduce altre complicazioni.

Dipende dai casi, comunque a mio parere la scelta più corretta sarebbe implementare classi con un'alto livello di astrazione e codice ottimizzato all'interno (in modo che, una volta implementato e testato per bene il codice interno, l'uso risulti facile e sicuro) in abbinamento a una buona parallelizzazione (es: elaborazione indipendente di più righe o sezioni dell'immagine)

[MItaly]

In sostanza: in assoluto un array di char è più veloce ma in realtà la scelta va valutata più cautamente

Questa è una sciocchezza: dato che una std::string o un std::vector<char> non sono altro che un array di char allocato sull'heap e incapsulato in una classe, l'accesso ai bytes è veloce esattamente come per gli array di char, dato che tutti i metodi di accesso vengono espansi inline (se si compila con le ottimizzazioni attive), e i controlli sugli indici sono attivi solo se lo chiedi (usando at() invece dell'operatore []).

Inoltre, a differenza degli array di char, hai a disposizione un sacco di metodi comodi, la gestione automatica della memoria, una semantica di copia ben definita e un sacco di altre comodità.

Il mio consiglio quindi è di usare assolutamente un std::vector<unsigned char>; unsigned non è strettamente necessario, ma è pratica comune usare degli unsigned char per dati binari, in genere ti consentono di risparmiare qualche cast qua e là nel codice.
Eviterei std::string non per motivi di performance, ma perché dà a chi legge il codice l'impressione che si stia lavorando con del testo, quando in realtà si tratta di dati binari.

[Caiodark]

Originariamente inviato da il_dordollano
Devo elaborare un file immagine .pixmap e vorrei anche utilizzare immagini medio grandi. Il programma sarà più veloce se uso array di char, se uso stringhe con le relative funzioni oppure è uguale?
A rigor di logica, essendo le stringhe degli array di char, dovrebbe essere identico il tempo, ma vorrei una conferma.

Ti consiglio di usare un tipo adatto (sicuro che char lo sia?) e di usare comunque i contenitori della libreria standard, i quali contengono già delle ottimizzazioni in base al tipo di dato che devono contenere.
Incapsula il tutto in una classe concreta in modo da disaccoppiare il contenitore dalla logica del tuo programma, così potrai testare diversi contenitori senza dover metter mano all'intero progetto.

[Scara95]

Originariamente inviato da MItaly
Inoltre, a differenza degli array di char, hai a disposizione un sacco di metodi comodi, la gestione automatica della memoria, una semantica di copia ben definita e un sacco di altre comodità.

E' appunto sulla gestione della memoria che puoi fare ottimizzazioni, almeno in questo caso è il punto di maggiore ottimizzazione (l'unico).

In ogni caso il guadagno in velocità non sarebbe poi così rilevante e avresti una perdita in astrazione e gestibilità del codice (che è quello che mi ostino a ripetere).

Originariamente inviato da Caiodark
Ti consiglio di usare un tipo adatto (sicuro che char lo sia?)

Char è l'unico tipo standard di 1 byte, unsigned char cambia solo il segno...

[MItaly]

Originariamente inviato da Scara95
E' appunto sulla gestione della memoria che puoi fare ottimizzazioni, almeno in questo caso è il punto di maggiore ottimizzazione (l'unico).

Un'immagine non può che essere allocata sull'heap (a meno che non sia veramente piccola) ed è di dimensioni fissate, per cui non è che ci sia tutta questa scelta nelle strategie di allocazione... in ogni caso tutti i container STL supportano come argomento template un oggetto allocatore custom.