[JAVA] string replacen

[roelio]

Op zaterdag 15 december 2001 22:51 schreef OiSyN het volgende:
ONE TAKEN!
en ga nu je excuses aanbieden aan mij

en nu coden!!

[mbravenboer]

Oei, ik heb weereens buggy code geproduceerd .

Ik vermoed dat er ergens een index ofzo niet helemaal goed staat...

[mbravenboer]

Zynth: deze zouden ze standaard in de String library moeten opnemen vind ik. is een errug handig methodetje

Er is dus tegenwoordig een methode die dit doet (en nog veel meer ). Als je in 1.4.0 kijkt zie je prachtig een replaceAll methode. Daar zijn ook de bench-marks van.

[ycode]

Heeft iemand van jullie al gekeken of je misschien niet de code van Sun kunt decompilen en dan kijken hoe zij het in jdk1.4.0 doen ?

[mbravenboer]

Je kan de source van de libs in de Java 2 SDK gewoon zien . Het staat echter ook vermeldt: het is niet alleen gemaakt voor het vervangen van Strings door andere Strings, het werkt namelijk met reguliere expressies. De code is dan ook heel simpel, omdat er gewoon doorverwezen wordt naar de nieuwe regex lib.

De fout die de topicstarter tegen kwam, had ik trouwens al hersteld in mijn eigen code.... Was nogal een stom probleem .

Hier is de goede code:

code:

public class ReplaceTest
{
    public static void main(String[] ps)
    {
        String text1 = "dit is een<I><U><B><I></I></B></U></I></I> markup</U>";
        StringBuffer text2 = new StringBufer(text1);
        String[] markuplist ={"<B>","</B>","<U>","</U>","<I>","</I>"};

      for(int i=0;i< markuplist.length; i++)
      {
         replaceUltraSnel(text2,markuplist[i],"");
           System.out.println("Na " + markuplist[i] + ", resultaat = " + text2.toString());
      }
    }


      public static String replaceUltraSnel(String source, String firstString, String newString)
    {
        return replaceUltraSnel(new StringBuffer(source), firstString, newString).toString();
    }

    public static StringBuffer replaceUltraSnel(StringBuffer source,  String firstString, String newString)
    {
        final int firstStringLength = firstString.length();
        final int newStringLength = newString.length();
        final char[] firstChars = firstString.toCharArray();
        final char[] newChars = newString.toCharArray();

        if(firstString.length() == newString.length())
        {
            int max = source.length() - firstStringLength;
            boolean equals = false;

            for(int i=0; i < max; i++)
            {
                equals = true;

                for(int j=0;j < firstStringLength; j++)
                {
                    if(source.charAt(i + j) != firstChars[j])
                    {
                        equals = false;
                        break;
                    }
                }

                if(equals)
                {
                    for(int j=0;j < firstStringLength; j++)
                    {
                        source.setCharAt(i + j, newChars[j]);
                    }
                    i += firstStringLength - 1;
                }
            }
        }
        else
        {
            int max = source.length() - firstString.length() + 1;
            int dif = newString.length() - firstStringLength;
            boolean equals = false;

            for(int i=0; i < max; i++)
            {
                equals = true;
                for(int j=0;j < firstStringLength; j++)
                {
                    if(source.charAt(i + j) != firstChars[j])
                    {
                        equals = false;
                        break;
                    }
                }

                if(equals)
                {
                    source.replace(i, i + firstStringLength, newString);
                    i = i + newStringLength - 1;
                    max = max + dif;
                }
            }
        }

        return source;
    }
}

Overigens kan je veel beter gebruik maken van de StringBuffer methode ipv steeds de String methode aan te roepen, zie hierboven. Daar is de StringBuffer methode namelijk voor bedoeld .

[mbravenboer]

Ter illustratie nog even de sourccode van String.replaceAll :

code:

public String replaceAll(String regex, String replacement)
{
    return Pattern.compile(regex).matcher(this).replaceAll(replacement);
}

[tomato]

mbravenboer: Ter illustratie nog even de sourccode van String.replaceAll :

Ach hoe schoon

[mbravenboer]

tomato :Ach hoe schoon

En bere traag, zie mijn eerdere bench-marks .

Bij herhaling van dezelfde replace zou het een stuk sneller moeten kunnen. Die code zuigt werkelijk IMHO .

[tomato]

mbravenboer: Bij herhaling van dezelfde replace zou het een stuk sneller moeten kunnen. Die code zuigt werkelijk IMHO .

Ja heb je helemaal gelijk in natuurlijk, ik zat maar te dollen

Valt me trouwens best tegen dat dergelijke functies echt heel inefficient geimplementeerd blijken

[mbravenboer]

tomato: Ja heb je helemaal gelijk in natuurlijk, ik zat maar te dollen

Voor deze keer dan .

Valt me trouwens best tegen dat dergelijke functies echt heel inefficient geimplementeerd blijken

Ja mij ook . Hebben ze bedacht dat voor gecompileerde reguliere expressies (Patterns) en gematchde strings (Matchers) zo leuk zijn, maken ze er zo enorm slecht gebruik van .

[Alarmnummer]

Ok.. met zijn alleen een snelle string lib maken?

[mbravenboer]

Hehe .

Op zich is het wel leuk om die Matcher te optimaliseren .

Wat vond je trouwens van mijn String - transformatie taaltje wat ik pas voorstelde als alternatief voor een String lib? Je kunt dit zelfs taal-onafhankelijk maken en naar verschillende talen gaan compileren . Je kunt enkele logische transformaties dan makkelijk daarin uitdrukken en aanbieden bij je tool .

[Verwijderd]

Martin we moesten je voordragen voor de Nobelprijs voor Java innovatie

[Alarmnummer]

ik denk niet dat ze zo snel worden als low level werk.

oja.. voor de liefhebbers.. ik ben al een tijdje bezig met een nieuwe site, (oude was erughhh lelijk ) en heb een tool gemaakt die een boom toevoegd op een html pagina op basis van xml bestandje..

http://www.geocities.com/peter_veentjer

ps. de site is nog lang niet klaar.. maar het gaat om het idee..

[mbravenboer]

Alarmnummer: ik denk niet dat ze zo snel worden als low level werk.

Je bedoelt dat taaltje? Dat denk ik dus juist wel . Kijk maar naar reguliere expressies die voor gecompileerd worden. Je kunt tijdens de compilatie allemaal leuke optimalisaties toepassen en zo ranzig mogelijke low-level code genereren. Je hebt dus een generieke oplossing die toch goede performance kan hebben. Uiteraard kan je over het algemeen specifieke gevallen altijd sneller maken, maar ik heb juist zo m'n twijfels bij specifieke gevallen .

oja.. voor de liefhebbers.. ik ben al een tijdje bezig met een nieuwe site, (oude was erughhh lelijk ) en heb een tool gemaakt die een boom toevoegd op een html pagina op basis van xml bestandje..

Cool . Je herrinert me aan m'n eigen site .

[Alarmnummer]

ik denk dat de meeste mensen in 90% van de gevallen belangstelling hebben bij eenvoudige replace/find routines. Maar het is wel een heel leuk idee.

[Alarmnummer]

waar is jouw site??

[mbravenboer]

Zef: we moesten je voordragen voor de Nobelprijs voor Java innovatie

Als die door Sun wordt uitgereikt zal dat niet zoveel zin hebben .

[mbravenboer]

Alarmnummer: waar is jouw site??

http://www.pandoramix.org niet voor niets uit m'n profile gehaald . Te lang niet onderhouden, te veel tik-fouten en er staat nog steeds niets op (na een jaar ).

[mbravenboer]

Alarmnummer: ik denk dat de meeste mensen in 90% van de gevallen belangstelling hebben bij eenvoudige replace/find routines.

Hum tja, misschien is dat wel weer zo, maar heb je dan genoeg functies om een lib te vullen?

[Verwijderd]

compleet offtopic...

Maar waar kiezen jullie normaal voor als het gaat om optimalisatie: geheugen of snelheid? (zit hier namelijk vaak mee)

Is er ergens een artikel beschreven (op het net) die een soort algemene richtlijn/aanwijzing aangeeft?

[mbravenboer]

tijnbraun: Maar waar kiezen jullie normaal voor als het gaat om optimalisatie: geheugen of snelheid? (zit hier namelijk vaak mee)

Meestal komt dit toch op hetzelfde neer bij Java: het maken van nieuwe objecten kost erg veel tijd en uiteraard ook geheugen. Object creatie beperken is dus het aller-belangrijkste en als je dat voorkomt sla je twee vliegen in 1 klap.

Is er ergens een artikel beschreven (op het net) die een soort algemene richtlijn/aanwijzing aangeeft?

Dit is een erg goed boek over Java Performance: Java Platform Performance: Strategies and Tactics. Je kan twee voorbeeld hoofdstukken downloaden .

[Alarmnummer]

Op zondag 16 december 2001 20:07 schreef tijnbraun het volgende:
compleet offtopic...

Maar waar kiezen jullie normaal voor als het gaat om optimalisatie: geheugen of snelheid? (zit hier namelijk vaak mee)

Is er ergens een artikel beschreven (op het net) die een soort algemene richtlijn/aanwijzing aangeeft?

over het algemeen optimaliseer ik nooit (hoogstends algoritme optimalisatie = macro optimalisatie). En als ik moet kiezen dan ga ik voor het besparen van cpu gebruik, gewoon hopen dat er genoeg geheugen is

[Verwijderd]

Ik was dit topic even aan het lezen en ik heb naar mijn menig al jaren een sneller code om strings te replacen.

Java:

    public String replaceString(String original, String pattern, String replace)
    {
        int originalLength = original.length();
        int patternLength = pattern.length();
        int lastIndex = 0, index = 0;
        StringBuffer result = new StringBuffer(originalLength * 2);
        char[] chars = new char[originalLength];

        while((index = original.indexOf(pattern, lastIndex)) >= 0)
        {
            original.getChars(lastIndex, index, chars, 0);
            result.append(chars, 0, index - lastIndex).append(replace);
            lastIndex = index + patternLength;
        }
        original.getChars(lastIndex, originalLength, chars, 0);
        result.append(chars, 0, originalLength - lastIndex);
        return result.toString();
    }

Als jullie die nou es in de benchmark gooien

Grtz

Dark

[Alarmnummer]

Tss... dat is tegenwoordig helemaal niet interessant meer

[hobbit_be]

DarkieDuck: wees gerust hij zal echt niet sneller zijn - aangezien je StringBuffers gebruikt en zelfs een IndexOF! . Er is nog een meer recent topic waar er nog wat meer wordt geprobeert met nog snellere algo's overigens is er no 1 optimal solution.

edit: ik weet niet hoe ik kan linken naar een topic maar het noemt: [java] code optimalisatie Daarin veel code en vele algo's - het kwam voort uit dit topic.

[ Voor 26% gewijzigd door hobbit_be op 12-09-2003 17:35 ]

[.oisyn]

Anyway, deze topic is dus al weer bijna 2 jaar oud.
Ik doe 'm even op slot, zodat ie weg kan zakken. Ik gooi 'm later weer open, maar mocht je deze sluitmessage lezen terwijl ie nog op slot zit, en we zijn alweer een tijdje verder, en je hebt wat interessants toe te voegen, mail me dan

.edit: woei ik dacht eraan (nou ja, ik kwam 'm tegen in mijn posthistory toen ik op zoek was naar wat anders ) Weer open dus

[ Voor 20% gewijzigd door .oisyn op 14-09-2003 14:13 ]