Mais rápidos .Net e SQL tipos de dados

Question

Espero que esta questão não é demasiado “campo de direito” e eu vou ser sincero em dizer que eu sou um newb em comparação com muitas pessoas sobre stackflow ...

Eu quero comparar representações de objetos de imagens, áudio e texto para um projeto de AI eu estou trabalhando. Eu gostaria de converter todos os três entradas em um único tipo de dados e usar um algoritmo de comparação central para determinar partidas estaticamente prováveis.

Quais são os tipos de dados “mais rápido” nativos NET e SQL para fazer comparações como esta? Na Net que tipo de dados requer a menor quantidade de conversões no CLR? Para SQL, que tipo pode ser “CRUD-ed” o mais rápido?

Eu estava pensando bytes para .Net e inteiros para SQL, mas inteiros representar um problema de ser um conceito dimensional. Você acha que as imagens e áudio devem ser tratadas no sistema de arquivo em vez de SQL ... Eu estou supondo assim ...

FWIW Eu estou construindo um robô a partir de peças que comprei na TrossenRobotics.com

Answer 1

Pessoalmente, se você precisa fazer comparações frequentes entre grandes objetos binários, eu botar os objetos e comparar os hashes.

Se os hashes não correspondem, então você pode ter certeza que os objetos não são iguais (que deve ser a maioria dos casos).

Se os hashes fazer jogo, então você pode começar uma rotina mais longa para comparar os objetos reais.

Este método só deve impulsionar o seu desempenho um pouco se você está comparando esses objetos com freqüência.

Answer 2

velocidade de tipos de dados é um pouco difícil de medir. Ele faz uma grande diferença se você estiver usando um sistema operacional de 32 bits ou de 64 bits. Por quê? Uma vez que determina a velocidade a que esses dados podem ser processados. Em geral, em um sistema de 32 bits, todos os tipos de dados que se encaixam dentro de 32 bits (int16, int32, carvão animal, de bytes, os ponteiros) serão tratados como a mesma velocidade. Se você precisar de grandes quantidades de dados a serem processados, é melhor dividi-la em blocos de quatro bytes cada um para o seu CPU para processá-los.

No entanto, quando você está escrevendo dados no disco, velocidade de dados tende a depender de fatores muito mais. Se o seu dispositivo de disco é em alguma porta USB, todos os dados são serializado, portanto, seria byte após byte. Nesse caso, o tamanho não importa muito, embora os menores blocos de dados deixaria os espaçamentos mais pequenos. (Em linguagens como Pascal você pode usar um registro embalado para este tipo de dados para otimizar streaming de desempenho, apesar de terem os seus campos em seus registros alinhados em múltiplos de 4 bytes para o desempenho da CPU.) discos regulares irá armazenar dados em blocos maiores. Para aumentar a leitura / escrita de velocidade, você preferir fazer suas estruturas de dados o mais compacto possível. Mas para o processamento de desempenho, tendo-os alinhados em 4 bytes limites é mais eficaz.

O que me lembra que uma vez eu tive uma discussão com alguém sobre o uso de compressão em um disco NTFS. Eu consegui provar que comprimir uma partição NTFS realmente pode melhorar o desempenho de um computador, uma vez que tinha que ler muito menos dados blocos, mesmo que isso significasse que tinha que fazer mais processamento para descomprimir os mesmos blocos de dados.

Para melhorar o desempenho, você só tem que encontrar o elo mais fraco (mais lento) e começar por aí. Uma vez que é otimizado, haverá um outro elo fraco ...

Answer 3

Pessoalmente, eu diria que você é melhor fora de usar um array de bytes. Você pode facilmente ler o arquivo para o buffer ... e do tampão na matriz de bytes, onde pode fazer a comparação.

Answer 4

Tanto quanto me lembro, em termos de desempenho puro, o tipo Int32 está entre os mais rápidos tipos de dados .NET. Não posso dizer se é o mais adequado na sua aplicação embora.

Answer 5

Antes de puxar qualquer coisa em .NET, você deve verificar o comprimento dos dados em SQL Server utilizando a função LEN. Se o comprimento é diferente, você já sabe que os dois objetos são diferentes. Isso deve salvar derrubar muitos dados desnecessários do SQL Server para o aplicativo cliente.

I também recomendar armazenar um código de hash (em uma coluna separada a partir dos dados binário) usando a função de verificação da soma ( http://msdn.microsoft.com/en-us/library/aa258245 (SQL.80) .aspx ). Isto só irá funcionar se você estiver usando SQL Server 2005 e acima e você está armazenando seus dados como varbinary (MAX). Mais uma vez, se os códigos de hash são diferentes, os dados binários é definitivamente diferente.

Se você estiver usando SQL Server 2000, você está preso com a 'imagem' tipo de dados.

Tanto a imagem ou varbinary (MAX) irá mapear muito bem para byte [] objetos no cliente, no entanto, se você estiver usando SQL Server 2008, você tem a opção de armazenar seus dados como um tipo de dados FILESTREAM ( http://blogs.msdn.com /manisblog/archive/2007/10/21/filestream-data-type-sql-server-2008.aspx ).