[Java] Fast Strings in Java

[alienfruit]

Ik ben op zoek na tips en trucs voor het snelle afhandelen van string opdrachten in Java, omdat ik bezig ben met optimaliseren van mijn parser. Het haalt nu maar 30mb/s , zo traag als stront van de makke beer dus Iemand enig tips/trucs?

[NMe]

Wat heb je al gezocht? En wat heb je gevonden? Wat was bruikbaar? Wat niet? En waarom?

Een topicstart van 3 zinnen kan beter.

[ACM]

Wat ook interessant is om te weten; wat voor bewerkingen doe je op je strings?

[alienfruit]

Ik hak een string van tussen de 300-400mb in stukjes Tokenizing etc. In Delphi kreeg ik me parser rond de ~70-100mb/s dat is dus maar 4-5seconden ipv. 10-14seconden in Java. 4-5 seconden is nog steeds langzaam

[RayNbow]

Als je met String's werkt, elke keer als je een bewerking op de String doet wordt er een nieuw String object aangemaakt. String's kunnen namelijk niet worden aangepast.

Java API: StringBuffer
Edit: een String in stukjes hakken lijkt me niet sneller gaan als je een StringBuffer gebruikt

[ Voor 19% gewijzigd door RayNbow op 12-12-2004 13:29 ]

[alienfruit]

Ja, in .NET moet je dan gebruik maken van StirngBuilder, ik dacht misschien moet je ook zoiets gebruiken in Java. Maar omdat ik een echte nitwitt ben in Java, zou ik het echt niet weten.

[flowerp]

Een beetje offtopic, maar wat is de toepassing? Iets met localisation? (mischien een parser die alle engelse termen in een stuk tekst opspoort en door nederlandse vervangt?)

[Verwijderd]

Een StringBuffer is aanzienlijk beter aangezien je een append doet ipv telkens een nieuwe String aanmaakt.

[mbravenboer]

Je wilt toch niet serieus beweren dat je een *string* van 300MB in je programma manipuleert? Je moet zulke hoeveelheiden data natuurlijk via een stream inlezen. Als je niet meer details geeft over je code, komt dit topic niet veel verder dan wat gezeur over Java performance.

Bovendien, heb je al een profiler gedraait?

[flowerp]

alienfruit schreef op zondag 12 december 2004 @ 13:34:
Ja, in .NET moet je dan gebruik maken van StirngBuilder, ik dacht misschien moet je ook zoiets gebruiken in Java. Maar omdat ik een echte nitwitt ben in Java, zou ik het echt niet weten.

Volgens de theorie is de StringBuilder class in Java nog sneller dan StringBuffer, dit omdat bij de eerste de synchronisatie weggelaten is. Als je toch maar vanaf 1 thread werkt heb je die ook helemaal niet nodig. Het rare is dat in de praktijk Java's StringBuilder dan weer helemaal niet sneller is. Je zou deze wel kunnen proberen of het in jouw situatie scheelt.

[gorgi_19]

* gorgi_19 gaat zich aansluiten bij mbravenboer

Ik heb het topic even aangekeken en echt lekker loopt het niet; vooral een giswerk naar mogelijkheden en specifieke toepassingen
Oftewel: alienfruit, pas je topic aan met meer info, zoals beschreven in P&W FAQ - De "quickstart". Zo niet, dan blijft dit topic een zweverig iets en gaat hij dicht

[ Voor 7% gewijzigd door gorgi_19 op 12-12-2004 13:42 ]

[alienfruit]

Ja, het is een simpele parser die een text adventure spel beschrijft, waarbij je een walkthrough kan beschrijven. Deze wordt dan geparsed waarbij er een AST onstaat die vervolgens wordt omgevormd na een werkbaar text adventure spel. Nu kwam mbravenboer met de opmerking om het gestreamed in te lezen, dat doe ik nu nog niet. Ik zal eens kijken of dat wat uitmaakt.

[mbravenboer]

Dat lijkt me erg verstandig ja: alleen al het in het geheugen hebben van zo'n gigantische string zal heel je systeem vertragen, zonder dat je er ook maar iets mee doet . Als je dit handig aanpakt en een stream en een char[] buffer hoeft er in principe geeneens een String aan te pas te komen.

[flowerp]

Wow. je streamde die data dus inderdaad niet. Ik ging er eigenlijk vanuit dat je dat wel zou doen. Ik ken geen enkele parser die dat normaliter niet doet; is ook niet erg practisch. Kijk maar eens hoe tokenizers / parsers als flex/bison werken. Flex werkt met een minimale buffer, bison slechts met 1 look-ahead character.

[Gert]

Dan nog is 75-100MB/s best veel, als dat bestand van schijf moet worden gelezen.

[flowerp]

Gert schreef op zondag 12 december 2004 @ 21:09:
Dan nog is 75-100MB/s best veel, als dat bestand van schijf moet worden gelezen.

Mischien is dat via dezelfde methode gemeten als dat je ook erop komt dat Delphi 300.000 regels in 1 seconde kan compilen?

Dit kwam een tijdje terug naar voren in een andere thread op got. Na een beetje doorvragen bleek dat het ging om code die helemaal niet gecompiled hoefde te worden. Mischien dat het buitenaardse wezen dat je niet verwachtte gewoon een stuk overslaat wat niet geparsed hoeft te worden? (en dus alleen de laatste 10MB ofzo inleest). Het is iniedergeval nogal gebruikelijk bij Delphi om dingen die je overslaat mee te rekenen.

Met de huidige technieken zou je al van een RAM disk moeten lezen, een gewone consumer HD in een non-raid opstelling gaat de 100MB/S over 300MB niet halen.

Alienfruit?

[alienfruit]

Die 75-100mb/s is natuurlijk alleen de tijd tussen het starten van het parsen en het beeindigen, Dan gewoon een rekensom maken Maar ik ben nog aan het pielen, ziekelijk geheugengebruik atm, maar tisch Java Ik denk dat ik het maar zo houd. Andere keer maar eens uitgebreid uitzoeken.

[ACM]

alienfruit schreef op maandag 13 december 2004 @ 01:26:
Maar ik ben nog aan het pielen, ziekelijk geheugengebruik atm, maar tisch Java

Tsja, 't is dat of jij kan gewoon niet (met Java) programmeren. Welke zal het zijn?

Door het simpele feit dat je nog steeds geen zinvolle code hebt getoond waar evt wat nuttige tips op gegeven kunnen worden heb ik een beetje het idee dat je er ook helemaal geen moeite voor wil doen. En dan vervolgens een opmerking met de strekking "het is tenslotte Java, dus het kan helemaal niet snel" is dan natuurlijk een beetje vreemd en tegen het zere been van mensen die regelmatig in Java hele snelle dingen maken.

[ Voor 3% gewijzigd door ACM op 13-12-2004 08:48 ]

[alienfruit]

Ach, laat ook maar. Ik houd het wel zo. Als jij voor mij gaat bepalen wat ik denk of zeg dan ben ik voor nu uitgepraat.

[ Voor 51% gewijzigd door alienfruit op 13-12-2004 13:07 ]

[.oisyn]

Het enige waar we nu nog op wachten is meer info van jouw kant, als dat niet komt dan kan deze topic natuurlijk net zo goed op slot.

Algemene tip: gebruik de juiste container voor de juiste taak. Een array/vector heeft de snelste implementatie in de zin van random access times, maar het zit aan een contiguous memory block vast wat nogal in het honderd kan lopen bij het toevoegen van heel veel elementen in meerdere stappen (wat resulteert in een allocatie van een nieuwe buffer die groot genoeg is, en dan een complete copy van de oude naar de nieuwe waarbij de nieuwe data ook toegevoegd wordt, en vervolgens het opruimen van de oude).