[java] Snelste manier op CSVfiles te verwerken.

[mkleinman]

In een tooltje die ik aan het schrijven ben doe ik ontzettend veel met het verwerken van CSV files. Aangezien ik een paar honderd Mb aan data moet inlezen wil ik dit het liefst op de snelst mogelijke manier doen.

Op dit moment blijft mijn code steken op circa 6.5Mb/sec inlezen.

Snelste tot nu toe is openCSV ( http://opencsv.sourceforge.net/ ) en daarmee per regel uitlezen en uitkomst stoppen in een String[].

Wat ik heb geprobeerd:

- SuperCSV library ( http://supercsv.sourceforge.net/ ). Qua opzet heel mooi alleen trager (4,3Mb/sec )
- openCSV in plaats van per regel bestand in 1x inlezen in een List en dan verder verwerken. Is ook trager ( 5Mb/sec )
- BufferedReader gebruiken per regel verwerken en data met split() in een String[] plaatsen. ( 4,3Mb/sec )

Iemand enig idee wat de snelste methode is om CSV informatie te verwerken? Het moet toch sneller kunnen?

[Domdo]

Heb je een idee van wat je bottleneck is ?

Mijn ervaring met CSV-files is dat het meestal toch echt de HDD is die de CPU lang niet kan bijhouden.

[Macros]

Ik zou zeggen, gebruik VisualVM om de applicatie te profilen.

[mkleinman]

Domdo schreef op zaterdag 16 oktober 2010 @ 10:32:
Heb je een idee van wat je bottleneck is ?

Mijn ervaring met CSV-files is dat het meestal toch echt de HDD is die de CPU lang niet kan bijhouden.

Om eerlijk te zijn geen idee wat de bottleneck is. Ik zal eens met VisualVM kijken of ik meer te weten kan komen waar de bottleneck zit.

[Creepy]

Eerst meten natuurlijk voordat je zaken gaat aanpassen. Wat je vaak wel ziet is dat meerdere regels tegelijk lezen m.b.v. een bufferedreader vaak sneller is dan simpelweg regel voor regel lezen. Maar als de CPU je bottleneck is gaat dat je ook niet helpen natuurlijk.

[mkleinman]

Creepy schreef op zaterdag 16 oktober 2010 @ 11:03:
Eerst meten natuurlijk voordat je zaken gaat aanpassen. Wat je vaak wel ziet is dat meerdere regels tegelijk lezen m.b.v. een bufferedreader vaak sneller is dan simpelweg regel voor regel lezen. Maar als de CPU je bottleneck is gaat dat je ook niet helpen natuurlijk.

Het klinkt mij zo onwaarschijnlijk dat mijn hardware de bottleneck is. Ik ben nu aan het testen op een Elitebook 8530w mobile workstation. En dat of 6.5mb/sec de bottleneck is of de Core 2 Duo T9600. Ik heb alleen op deze schaal van performance tunen nog niet zo heel veel ervaring met Java.

Met BufferedReader meerdere regels inlezen kan ik nog proberen.

[keesdewit]

Waar moet die data dan uiteindelijk in terecht komen? Als het in een database moet komen dan zijn er binnen bepaalde database engines snellere methodes zoals bulk insert.

[Matis]

Volgens mij kun je dit prima met een producer/ consumer model oplossen. Ik denk dat het verstandig is om de CSV-data met (bijvoorbeeld) blokken van omstreeks 16 meg in te lezen in een string met de producer.
Dan heb je een consumer-thread die de string omzet naar een applicatie-specifieke indeling.
Op die manier snijdt het mes aan twee kanten en zal het bestand zo snel mogelijk ingelezen worden. Als de beperkende factor in de CPU-kracht zit, dan wordt er even wat meer data gebufferd (geheugengebruik), maar ik neem aan dat dat niet de bottleneck zal zijn.

[CodeCaster]

Je bent het nu waarschijnlijk seriëel aan het verwerken: eerst een stukje inlezen, dan een stukje verwerken, dan een stukje opslag. Dat alles wacht op elkaar.

Als dat het geval is zul je dit parallel moeten gaan maken.

[Voor 12% gewijzigd door CodeCaster op 16-10-2010 16:28]

[Killemov]

CodeCaster schreef op zaterdag 16 oktober 2010 @ 16:13:
Je bent het nu waarschijnlijk seriëel aan het verwerken: eerst een stukje inlezen, dan een stukje verwerken, dan een stukje opslag. Dat alles wacht op elkaar.

Als dat het geval is zul je dit parallel moeten gaan maken.

+1, DUH, *kuch*NIO*kuch*

OpenCSV doet dit waarschijnlijk toch al. Dus eerst meten, oh nee, toch eerst een interface vaststellen. (Zodat je later een eventueel snellere implementatie gemakkelijk kunt inswappen.)

[RayNbow]

flitspaal.nl schreef op zaterdag 16 oktober 2010 @ 10:08:
- BufferedReader gebruiken per regel verwerken en data met split() in een String[] plaatsen. ( 4,3Mb/sec )

Dit gaat iig niet goed met alle CSV files.

[Robtimus]

Heb je al CSVReader geprobeerd icm BufferedReader? Dus CSVReader niet direct een FileReader meegeven maar een BufferedReader wrapper om de FileReader heen?

[Hydra]

RayNbow schreef op maandag 18 oktober 2010 @ 06:22:
Dit gaat iig niet goed met alle CSV files.

Inderdaad. Textvalues kunnen vrijwel alle karakters bevatten, dus ook (punt)komma's. Je mag niet splitten binnen de quotes die een textvalue omsluiten. Dit is volgens mij ook de reden dat bijna iedere dev wel een keer een CSV splitter schrijft

[pedorus]

flitspaal.nl schreef op zaterdag 16 oktober 2010 @ 10:08:
- BufferedReader gebruiken per regel verwerken en data met split() in een String[] plaatsen. ( 4,3Mb/sec )

Even ervan uitgegaan dat dit kan omdat je geen dingen als escaping, quotes of multi-line-issues hebt, dan moet je bedenken dat split() niet erg snel is. Dit komt omdat de split voor regex werkt. Zie bijv. Performance of string tokenisation: String.split() and StringTokenizer compared.

Voor de rest zal het nogal uitmaken waar de data heen moet wat hier het handigst is... Ik denk dat de snelheid van opencsv sowieso wel verbeterd kan worden, bijvoorbeeld omdat daar steeds een nieuwe arraylist gemaakt (regel 195) wordt.

[mkleinman]

keesdewit schreef op zaterdag 16 oktober 2010 @ 12:56:
Waar moet die data dan uiteindelijk in terecht komen? Als het in een database moet komen dan zijn er binnen bepaalde database engines snellere methodes zoals bulk insert.

Data wordt verwerkt in een paar interne objecten waarna ik er grafieken mee produceer ( http://morpheus.flitspaal.nl/graphs ). Het tooltje wat ik heb gemaakt leest de logfiles van mijn omvormers ( zonnepanelen ) uit en daar maak ik grafieken mee.

Inlezen van de data is absoluut niet de bottleneck. Als ik het verwerken van de data uitcommentarieer dan schiet de performance omhoog naar 50-60Mb/sec.

Ik zal in elk geval nog eens kijken of ik een BufferedReader kan gebruiken ipv een filereader en of dat verschil uitmaakt.

Ik hoop dat ik er vandaag nog aan toe kom.

[Robtimus]

Met 50-60MB/s inlezen bedoel je via CVSReader? Of is dat met een simpele BufferedReader? In het eerste geval zit de bottleneck niet in het inlezen maar het verwerken. Als het verwerken een factor 10 vertragend is dan zou ik mijn focus daarop leggen, en niet op het leesgedeelte.