C# + Mono : In memory extraction bzip2

[Tharulerz]

Ik zit met het volgende scenario:

Files (een paar honderdduizend per dag) worden gedownload van een webserver over http door een c# applicatie. Deze files moeten vervolgens uitgepakt worden (bz2) en daarna geparsed/verwerkt.

Dit alles moet zo performant mogelijk gebeuren.

Het probleem stelt zich bij het uitpakken met bz2:

De snelste implementatie die ik kon vinden is http://sevenzipsharp.codeplex.com/ , die probleemloos werkt op windows. Echter, deze werkt niet op mono omwille van hebt gebruik van een unmanaged dll via COM.

Andere implementaties werken wel, maar zijn veel te traag (factor 10 en meer in vergelijking met sevenzipsharp, dus niet echt een oplossing).

Ik zoek een manier om alsnog op een snelle manier te extracten draaiende op mono, zonder naar disk te schrijven (dus met byte array in memory decompression).

Iemand een idee? Heb reeds alle c# libraries afgegaan, en ben niet zon held in heel dit unmanaged gedoe. Ik zou denken dat het hier mee kan: http://www.mono-project.com/Interop_with_Native_Libraries maar ik heb geen idee hoe eraan te beginnen.

Alvast bedankt.

[creator1988]

Start bz2, pipe je file erheen en pipe de stdout terug naar je programma. Verwerken terwijl de data binnenkomt, is allemaal streaming.

[HMS]

Heb je hier iets aan?

http://stackoverflow.com/...ib-bzip2-and-mono-support

(Eerste hit op Google)

[leuk_he]

Draai je mono op windows? dan lijken die (laatste) links het toch aardig te beschrijven toch?

een unmanaged versie zal vast en zeker sneller zijn dan een 100% mono implementatie. In memory houden zal zeker sneller zijn..

Andere oplossing is dat je de files uitpakt naar een temp fs Dan komen er ook geen diskwrites bij kijken.

Maar goed, elke keer een programma aanroepen om eenfile uit te pakken kost wellicht ook wel veel overhead. Wellicht kun je dat gedeelte helemaal in een unmanaged (C/C++) omgeving schrijven.

[Tharulerz]

@HMS: Reeds geprobeerd, werkt wel, maar is 10 keer trager dan sevenzipsharp, geen optie dus.

@leuk_he: Mono draait op ubuntu. Heb het nu inderdaad geimplementeerd met een temp fs, en performance is ok, maar heb het gevoel dat het nog efficienter zou moeten kunnen.

[Soultaker]

Hoe bevalt creator1988's suggestie? (edit: de tool die je zoekt heet bzcat.)

En als je helemaal van de externe tools afwil: SWIG gebruiken om libbz2 te wrappen zodat je gewoon de native library aan kunt spreken? (Die moet toch goede performance bieden!)

[ Voor 9% gewijzigd door Soultaker op 10-12-2012 16:09 ]

[Kaw]

Ik kwam ook uit op SharpZipLib. Juist vanwege het ontbreken van de externe referenties is het een stuk trager. Native .Net en zeker Mono is traag wanneer het gaat om compressie-algoritmen. Maar een factor 10 kan ik haast niet geloven. Zelf gebruik ik de library om OpenStreetMap worldfiles in te lezen en dat gaat qua performance redelijk goed.

[Feanathiel]

Tharulerz schreef op zondag 09 december 2012 @ 20:57:
[...]
Iemand een idee? Heb reeds alle c# libraries afgegaan, en ben niet zon held in heel dit unmanaged gedoe. Ik zou denken dat het hier mee kan: http://www.mono-project.com/Interop_with_Native_Libraries maar ik heb geen idee hoe eraan te beginnen.

[...]

Als ik het zo zie, dan exporteert de shared library dezelfde methode aanroepen als hier worden genoemd. Simpelweg een .so bakken van libbz2 moet voldoende zijn om het werkende te krijgen. Uiteraard wel even 'bzip2.dll' bij de DllImports aanpassen naar de nieuwgebakken .so. Voorbeeld gebruik alhier te vinden.

[Tharulerz]

Soultaker schreef op maandag 10 december 2012 @ 16:06:
Hoe bevalt creator1988's suggestie? (edit: de tool die je zoekt heet bzcat.)

Is er een makkelijke manier om binary files te pipen naar een extern proces dan (zonder een wrapper te schrijven voor dat proces)? Voor zover ik weet heb je enkel een streamwriter ter beschikking, en die neemt alleen strings aan.

Soultaker schreef op maandag 10 december 2012 @ 16:06:
En als je helemaal van de externe tools afwil: SWIG gebruiken om libbz2 te wrappen zodat je gewoon de native library aan kunt spreken? (Die moet toch goede performance bieden!)

Ik zoek het even uit, goede suggestie

Kaw schreef op maandag 10 december 2012 @ 17:01:
Ik kwam ook uit op SharpZipLib. Juist vanwege het ontbreken van de externe referenties is het een stuk trager. Native .Net en zeker Mono is traag wanneer het gaat om compressie-algoritmen. Maar een factor 10 kan ik haast niet geloven. Zelf gebruik ik de library om OpenStreetMap worldfiles in te lezen en dat gaat qua performance redelijk goed.

Dan moet je het toch echt eens benchmarken tegen 7z.dll unmanaged, die is echt super snel. (Hangt misschien ook wel van filesizes af).

[HMS]

De vraag is natuurlijk: "Is de performance acceptabel?" Zo ja, is er niks aan de hand. Zo nee, dan moet je inderdaad naar unmanaged dll's gaan kijken. Maar goed, ik neem aan dat je dat in je benchmark hebt meegenomen