Applicazioni associate alla CPU vs. IO associate

Question

Per le applicazioni in stile 'numero decrescente' che usano molti dati (legge: "centinaia di MB, ma non in GB", cioè, si adatta perfettamente alla memoria accanto al sistema operativo), ha senso leggere tutto i tuoi dati in memoria prima di iniziare l'elaborazione per evitare di rendere potenzialmente legato il tuo IO del programma durante la lettura di set di dati correlati di grandi dimensioni, invece di caricarli dalla RAM?

Questa risposta cambia tra l'utilizzo di diversi supporti dati? vale a dire, la risposta sarebbe la stessa indipendentemente dal fatto che si stessero usando file XML, file flat, un DBMS completo, ecc.?

Answer 1

Il tuo programma è veloce come qualunque sia il suo collo di bottiglia. Ha senso fare cose come la memorizzazione dei dati in memoria se ciò migliora le prestazioni complessive. Non esiste una regola rigida che dica che migliorerà le prestazioni. Quando si corregge un collo di bottiglia, qualcosa di nuovo diventa il collo di bottiglia. Pertanto, la risoluzione di un problema può comportare un aumento dell'1% delle prestazioni o del 1000% a seconda del prossimo collo di bottiglia. La cosa che stai migliorando potrebbe essere ancora il collo di bottiglia.

Penso che queste cose si inseriscano generalmente in uno dei tre livelli:

1. Desideroso. Quando hai bisogno di qualcosa dal disco o da una rete o il risultato di un calcolo, vai e lo ottieni o lo fai. Questo è il più semplice da programmare, il più semplice da testare ed eseguire il debug ma il peggio per le prestazioni. Questo va bene purché questo aspetto non sia il collo di bottiglia;
2. Lazy. Una volta effettuata una lettura o un calcolo particolare, non farlo di nuovo per un certo periodo di tempo, che può variare da pochi millisecondi a sempre. Ciò può aggiungere molta complessità al programma, ma se la lettura o il calcolo sono costosi, possono trarre enormi vantaggi; e
3. Eccessivo. È molto simile a una combinazione dei due precedenti. I risultati vengono memorizzati nella cache ma invece di eseguire la lettura o il calcolo o richiesto c'è una certa quantità di attività preventiva per anticipare ciò che potrebbe desiderare. Come se leggessi 10K da un file, c'è una probabilità ragionevolmente alta che potresti desiderare in seguito il prossimo blocco 10K. Invece di ritardare l'esecuzione, la ottieni nel caso in cui sia richiesta.

La lezione da trarre da questa è la citazione (un po 'troppo utilizzata e spesso citata erroneamente) di Donald Knuth secondo cui "l'ottimizzazione prematura è la radice di tutti i mali". Le soluzioni entusiaste e troppo entusiaste aggiungono un'enorme quantità di complessità, quindi non ha senso farle per qualcosa che non produrrà un beneficio utile.

I programmatori spesso commettono l'errore di creare una versione (presunta) altamente ottimizzata di qualcosa prima di determinare se ne hanno bisogno e se sarà utile o meno.

La mia opinione su questo è: non risolvere un problema fino a quando non hai un problema.

Answer 2

Immagino che la scelta del giusto metodo di archiviazione dei dati avrà un effetto maggiore rispetto al fatto che tu legga dal disco tutto in una volta o secondo necessità.

La maggior parte delle tabelle del database ha offset regolari per i campi in ogni riga. Ad esempio, un record cliente può essere lungo 50 byte e avere una colonna pants_size che inizia al dodicesimo byte. Selezionare tutte le taglie di pantaloni è facile come ottenere valori negli offset 12, 62, 112, 162, fino alla nausea .

XML, tuttavia, è un formato scadente per un rapido accesso ai dati. Per ottenere i tuoi dati dovrai scorrere una serie di tag e attributi di lunghezza variabile e non sarai in grado di passare istantaneamente da un record all'altro. A meno che non si analizzi il file in una struttura di dati come quella sopra menzionata. Nel qual caso avresti qualcosa di molto simile a un RDMS, quindi ecco qua.