Processando arquivos grandes (CSV) em .NET

(VEJA A ERRATA ABAIXO) Neste vídeo comparamos algumas alternativas para processar arquivos grandes. Os resultados obtidos variam bastante tanto em complexidade, quanto em memória alocada e tempo de processamento.
Esse vídeo é uma edição dos Drops da EximiaCo.tech. Trata-se de uma versão ampliada e revisada de uma das principais publicações de nossos sites.
O post original está em: www.eximiaco.t...
ERRATA
São considerados objetos grandes aqueles maiores que 85000 bytes (~84K e não exatamente)
Objetos LOH (mais que 85000bytes) são coletados junto com GEN2, mas a memória não é compactada.
A compactação de LOH pode ser solicitada pelo programador a partir do .net 4.51
** NÃO DEVEMOS INTERAGIR COM GC A MENOS QUE SAIBAMOS EXATAMENTE AS CONSEQUÊNCIAS **
O dataset utilizado no vídeo pode ser obtido em:
grouplens.org/...
Os drops da EximiaCo, em áudio, estão disponíveis nas principais plataformas:
Spotify
open.spotify.c...
Apple Podcasts
podcasts.apple...
Deezer
www.deezer.com...
Soundcloud
/ eximiaco

[@HumbertoPereira1994]

quanto mais eu aprendo, mais eu vejo que eu não sei nada kkk.. muito obrigado Elemar Jr

[@rodcorporation]

Caraca Elemar!! kkkkk Sou viciado em questão performance, e melhoria de escrita de código. Adoro posts assim e ainda com vídeo fica sensacional! Muito obrigado por estes posts e os vídeos! no aguardo do próximo!

[@burilec]

Um vídeo interessante seria sobre coleções para cada cenário entre performance e facilidade de manter ou até criar uma coleção

[@lucianomattos5942]

Muito show esse video. Onde trabalho, uma de minhas funções é criar rotinas para processamento de arquivos enviados pelos clientes, são arquivos do tipo csv, sap, rdi, access, planilhas excel, afp, metacode, pdf, etc..., Tem remessa de arquivos, que somados, passam de 1TB. Tenho que ler e escrever esses arquivos preparando para outro sistema. Tive que criar rotinas de processamento semelhante o exemplo 4 do video para ter desempenho e cumprir o SLA. Mas sem duvidas que esse video vai ajudar eu melhorar mais ainda o desempenho das minhas rotinas, só tenho a agradecer.

[@alexsandromartins]

Muito legal , parabéns pelo vídeo O que mais gostei é que você é pé no chão e sabe que tudo depende do cenário da necessidade . A maioria dos caras são doentes , pra mostrar que sabem mais que os outros e fazem malabarismos pra economizar imperceptíveis milissegundos e fazem um código que pouco gente consegue dar manutenção . Valeu. Obrigado

[@mupezzuol]

Vídeo mais perfeito que eu já vi, sobre diferenças de implementações com as performances etc.. Muito bom, poderia fazer para Java também kkkkk sou dev java

[@luizcarlosmarques1531]

Obrigado pela explicação, perfeito. Estou exatamente com esse problema. Vlw!

[@rogerflopes]

Excelente Elemar! Ha uns anos atrás participei da construção de um projeto que precisava ler diversos tipos de arquivos gigantescos pela rede. Inicialmente o processo levava em torno de 15 minutos e conseguimos reduzir para certo de um minuto. Se tivesse feito estas melhorias com GC iria com certeza ser muito mais rápido! Valeu!

[@leandrostoneshop]

Como sempre excelente. A última abordagem é impressionante.

[@cleitoncarlospereira2006]

Vídeo extremamente explicativo, vira e mexe caímos neste cenário de leitura de arquivos e este vídeo nos dá a possibilidade de implementação para vários cenários. Obrigado pelo vídeo

[@ermersonrafael]

Se fosse possível, daria mais likes só pela parte do momento bloguerinho. Que conteúdo fantástico, isso desperta um interesse enorme em buscar mais conteúdo sobre.

[@PatrickReinan]

Eu já havia lido este artigo e me fez pensar bastante sobre alocações de memória. Além deste ponto, este video ainda mostra a flexibilidade que C# possui entre o alto nível e baixo nível. Excelente video Elemar!

[@Canikrause]

Show Elemar. Usei a mesma lógica no primeiro ajuste de performance em uma prova de um banco e fui informado que fiz de ma maneira errada. Fico mais tranquiko em saber que não estou tao errado assim.

[@leandrolagoa]

Que animal, curti demais o vídeo! São coisas relativamente simples, mas que fazem toda diferença nas implementações do dia a dia. Elemar, queria deixar uma sugestão, seria possível fazer um vídeo nesse mesmo estilo mostrando boas práticas para uma aplicação ASP.NET CORE usando EF Core e um banco de dados. Acho que seria legal mostrar a diferença de desempenho em um CRUD aplicando boas práticas. Acha que seria possível? A galera aí que se interessa tbm deixa um curtir no comment pra ajudar o Elemar ver! kkkkkkkk

[@brunogomes4113]

Excelente , faço muito uso desse tipo de rotina , vou testar na minha aplicação essas implementações pra ver o ganho de performance

[@renandexterp1]

Muito legal Elemar, simples, direto e com um bom conteúdo, vou ver mais.

[@Mec2005]

Parabéns Elemar, continue nos presenteando com estes excelentes conteúdos que todos programadores deveriam conhecer!

[@magobeta5489]

Conteúdo diferenciado mesmo.

[@FenixPSDG]

Incrível

[@AlbertoMonteiro]

Maravilha de vídeo!!! Sobre a complexidade do ultimo algoritimo, sabendo que é um csv, se ao invés de usar um buffer de 1MB, fosse criando buffers mais "dinamicos" a cada que fosse encontrado, sendo assim saberiamos que o registro estaria "completo". Você acha que dessa forma a complexidade iria diminuir?

[@elemarjr]

Daí eu teria objetos demais alocados na HEAP (cada buffer) e acionamentos da GC. :)

[@thiagocustodio8177]

Obrigado por compartilhar mestre, excelente video.

[@wellyngtond2]

Perfeito.

[@PedroIgor91]

Seria legal se você disponibilizasse os códigos no Github Mestre! A comunidade vai adorar!

[@alvarobernardi1]

Parabéns pelo vídeo e pela didática, sou iniciante de C# e estou tentando aprender mais sobre essa leitura de planilhas, e descobri que o método que uso é um dos que vc recomendou ( método 2 - que poderia ser o padrão ). Más gostaria de saber se tem como melhorar o lançamento dos dados para um banco de dados (mysql), porque tenho 10 planilhas e elas tem mais de 1gb e o processo todo esta levando aprox 9 dias. Estava estudando e tentando colocar de forma assíncrona a leitura delas, más esta dando erro, pois esta dando problema quando tento incluir os dados, então estou vendo para ler as planilhas de modo assíncrona e criando um arquivo com as informações separadas e somente depois começar a fazer realmente a importação dos dados, pois verifique que a demora não esta na leitura da planilha e sim no momento que passo a informação para o banco de dados. Com a forma que vc passou, descobri que a leitura da planilha sem o envio dos dados para o banco, esta durando 21 seg com 26mb de memória utilizada, só que meu split tem 27partes, a planilha que usei de teste tem 4.753.435 registros e foram selecionados 1.385.132 e também não estou usando o console, talvez explique a diferença enorme para a sua pesquisa 16seg

[@ThugLifeModafocah]

Esse vídeo foi realmente muito bom. E como ficaria a performance em caso de parallelismo e uso de todos os cores da máquina?

[@luisflavioaquino]

Você é um monstro!

[@carlosl8832]

👍👍

[@10ENRASKA]

Olá, excelente explicação. Me tira uma dúvida, como eu leio vários arquivos .csv de uma vez que estão em uma pasta?

[@vinybas]

Elemar, posso fazer uma correção? Você disse que objetos acima de 84KB o GC não coleta. Não é bem assim. Objetos acima de 85KB ele trata de forma diferente, ele aloca no LOH ("geração 3"), e só é desalocado em 3 casos específicos: quando o limite da geração é excedido, quando o SO está com pouca memória disponível, ou manualmente. Cheguei no seu vídeo por essa frase, um zé ruela tava defendendo ficar chamando GC.Collect manualmente e usou teu vídeo como argumento (o que você obviamente não ensinou), dizendo que o GC não funciona direito. Apesar dessa correção, achei o vídeo muito bom.

[@eduardoduarte4165]

Show! 👏🏼👏🏼👏🏼

[@EximiaCo]

Correção da correção. :) 1. LOH não é a mesma área de GEN3. 2. O objeto é 85000 bytes (~84K pois 1K=1024 bytes) 3. Eles são sim coletados em G2, mas o LOH não é compactado mantendo o working set grande. 4. A partir do dotnet 4.51 é possível especificar compactação de maneira deterministica. No mais, seu colega está inteiramente errado. GC.Collect, mal utilizado, confunde o GC, atrapalhando seu funcionamento e PIORA a performance.

[@elemarjr]

Obrigado pelo feedback. Já fiz as considerações no comentário anterior.

[@elemarjr]

Editei as notas com observações :) Obrigado @Vinicius Bastos.

[@vinybas]

@@EximiaCo 1. Realmente não existe uma "GEN 3" de verdade. Usei como referência para essa expressão, chamando a LOH de GEN 3, esse link, 2º parágrafo da Gen 0: docs.microsoft.com/pt-br/dotnet/standard/garbage-collection/fundamentals#generations 2. Você está certo! Desculpe pelo meu engano, errei no cálculo rs! 45000 = 83,0078125‬, dá pra considerar ~84KB arredondando pra cima, não está errado. 3.Pelo que entendi, e posso ter entendido errado, objetos grandes são alocados na LOH (suposta "GEN 3"), mas são coletados pela GEN2. Isso não está totalmente claro para mim, mas foi o que entendi nesse artigo: docs.microsoft.com/pt-br/dotnet/standard/garbage-collection/large-object-heap 4. Absolutamente certo. Obrigado pela resposta!

[@alef.carlos]

Muito bom, como sempre. rs ! Um ponto interessante de se mostrar: como é possível eu saber quantos k tem meu o objeto ?

[@hiramfernandes]

Realmente, já que esses 84k mencionados fazem tanta diferença, é bom saber o tamanho do objeto.

[@guilhermecaixeta8080]

Muito bom, parabens pelo otimo video

[@valdrianooliveira3834]

muito bom, amigo agora como eu faria para melhorar a performace quando se trabalha com DataSet Tipado, usando banco de dados?

[@Esmerexpx]

Muito bom Tio Elemar! Só uma dúvida, porque quando vc cria um array no ultimo código ele não marca alocação dele no heap? É porque só marca objetos que foram coletados?

[@raphaelnara]

Elemar, o uso de arrays de bytes nao deveria contabilizar objetos já que um array eh um objeto?