Tipi di dati .Net e SQL più veloci

Question

Spero che questa domanda non sia troppo "campo giusto" e sarò sincero nel dire che sono un principiante rispetto a molte persone su Stackflow...

Voglio confrontare le rappresentazioni di oggetti di immagini, audio e testo per un progetto di intelligenza artificiale su cui sto lavorando.Mi piacerebbe convertire tutti e tre gli input in un unico tipo di dati e utilizzare un algoritmo di confronto centrale per determinare le corrispondenze staticamente probabili.

Quali sono i tipi di dati nativi .Net e SQL "più veloci" per effettuare confronti come questo?In .Net quale tipo di dati richiede il minor numero di conversioni nel CLR?Per SQL, quale tipo può essere "CRUD-ed" più veloce?

Stavo pensando ai byte per .Net e agli interi per SQL, ma gli interi pongono il problema di essere un concetto unidimensionale.Pensi che le immagini e l'audio dovrebbero essere gestiti all'interno del file system anziché in SQL... immagino di sì...

FWIW Sto costruendo un robot con parti che ho acquistato su TrossenRobotics.com

Answer 1

Personalmente, se avete bisogno di fare confronti frequenti tra grandi oggetti binari, vorrei hash gli oggetti e confrontare gli hash.

Se gli hash non corrispondono, allora si può essere sicuri che gli oggetti non corrispondono (che dovrebbe essere la maggior parte dei casi).

Se gli hash corrispondono, si può quindi iniziare una più lunga routine per confrontare gli oggetti reali.

Questo metodo solo dovrebbe aumentare le prestazioni un po 'se si sta confrontando spesso questi oggetti.

Answer 2

La velocità dei tipi di dati è un po' difficile da misurare.Fa una grande differenza se utilizzi un sistema operativo a 32 bit o 64 bit.Perché?Perché determina la velocità con cui questi dati possono essere elaborati.In generale, su un sistema a 32 bit, tutti i tipi di dati che rientrano in 32 bit (int16, int32, carattere, byte, puntatori) verranno elaborati alla stessa velocità.Se è necessario elaborare molti dati, è meglio dividerli in blocchi di quattro byte ciascuno affinché la CPU possa elaborarli.

Tuttavia, quando scrivi dati su disco, la velocità dei dati tende a dipendere da molti più fattori.Se il tuo dispositivo disco si trova su una porta USB, tutti i dati vengono serializzati, quindi sarebbero byte dopo byte.In tal caso, le dimensioni non contano molto, anche se i blocchi di dati più piccoli lascerebbero spazi vuoti più piccoli.(In linguaggi come Pascal, si usa un record pieno per questo tipo di dati per ottimizzare le prestazioni di streaming, pur avendo i campi nei record allineati a multipli di 4 byte per le prestazioni della CPU.) I dischi regolari memorizzeranno i dati in blocchi più grandi.Per aumentare la velocità di lettura/scrittura, preferiresti rendere le tue strutture dati il ​​più compatte possibile.Ma per le prestazioni di elaborazione, allinearli sui limiti di 4 byte è più efficace.

Il che mi ricorda che una volta ho discusso con qualcuno sull'uso della compressione su un disco NTFS.Sono riuscito a dimostrare che la compressione di una partizione NTFS poteva effettivamente migliorare le prestazioni di un computer poiché doveva leggere molti meno blocchi di dati, anche se ciò significava che doveva fare più elaborazione per decomprimere gli stessi blocchi di dati.

Per migliorare le prestazioni, devi solo trovare il collegamento più debole (più lento) e iniziare da lì.Una volta ottimizzato, ci sarà un altro anello debole...

Answer 3

Personalmente, direi che si sta meglio fuori usando un array di byte. Si può facilmente leggere il file in al buffer ... e dal buffer in array di byte in cui è possibile fare il confronto.

Answer 4

Per quanto mi ricordo, in termini di prestazioni pura, il tipo Int32 è tra i tipi di dati più veloci di .NET. Non posso dire se è il più adatto nell'applicazione però.

Answer 5

Prima di tirare qualsiasi cosa in .NET, si dovrebbe verificare la lunghezza dei dati in SQL Server utilizzando la funzione LEN. Se la lunghezza è diversa, si sa già che i due oggetti sono diversi. Questo dovrebbe salvare abbattere un sacco di dati non necessari da SQL Server per l'applicazione client.

Consiglio anche memorizzare un codice hash (in una colonna separata dai dati binari) utilizzando la funzione CHECKSUM ( http://msdn.microsoft.com/en-us/library/aa258245 (SQL.80) .aspx ). Questo funziona solo se si utilizza SQL Server 2005 e sopra e si archiviano i dati come varbinary (MAX). Ancora una volta, se i codici hash sono diversi, i dati binari è decisamente diverso.

Se si utilizza SQL Server 2000, si è bloccato con il tipo di dati 'immagine'.

Sia immagine o varbinary (MAX) saranno mappare bene per byte [] oggetti sul client, se si utilizza SQL Server 2008, si ha la possibilità di memorizzare i dati come tipo di dati FILESTREAM ( http://blogs.msdn.com /manisblog/archive/2007/10/21/filestream-data-type-sql-server-2008.aspx ).