Vlákno názorů k článku Monitorování procesů a správa paměti v JDK6 a JDK7 (2) od Filip Jirsák - Nejčastější použití StringBufferu/strin­gBuilderu je pravděpodobně spojování řetězců. Proč...

  • Článek je starý, nové názory již nelze přidávat.
  • 13. 1. 2011 9:49

    Filip Jirsák (neregistrovaný)

    Nejčastější použití StringBufferu/strin­gBuilderu je pravděpodobně spojování řetězců. Proč v JDK není třída optimalizovaná pro tuhle operaci, a nepoužívá se pro spojování řetězců (i operátory + a +=) právě taková třída? Pro pouhé spojování řetězců přece není nutné obsah řetězců neustále kopírovat a postupně rozšiřovat buffer. Stačí si zapamatovat posloupnost řetězců a na konec (při volání toString()) najednou vytvořit buffer požadované délky a do něj obsahy zkopírovat najednou – jak to dělá např. jodd.util.Strin­gBand.

  • 13. 1. 2011 13:29

    kuka (neregistrovaný)

    Ono v JDK neni rada dalsich mozna sikovnych veci. Skutecne zavazne problemy zpusobuje pouze spojovani v cyklu, coz by takova trida stejne neresila.

    Na druhe strane ukladani retezcu muze byt dost pametove neusporne - extremem je priklad v clanku, kdy se pridavaji jen cisla a mezera. Konkretne StringBand by obsahoval obrovske pole, pro cisla by navic vznikly jejich String reprezentace (a String je velice pametove "drahy" objekt). Proste pro kazdy ucel se hodi neco trochu jineho, StringBuilder je podle mne pro spojovani rozumny kompromis, ktery nikomu nezpusobi prusvih. Pokud je pro to duvod, neni problem si naprogramovat neco na miru.

  • 13. 1. 2011 18:38

    Pavel Tišnovský
    Zlatý podporovatel

    Mate pravdu, ten priklad v clanku je dovedeny do extremu, ale podobny problem se Stringy uz jsme resili nekolikrat. Napriklad v databazi Hypersonic (dnes HSQLDB) existuji tridy, ktere dokazi cele databazove schema vyexportovat do textoveho souboru jako SQL-skripy obsahujici prikazy typu CREATE TABLE a nekdy i data, tj. INSERT INTO.

    Ovsem predevsim ve starsich verzich se tyto prikazy skladaly do Stringu, ktere se potom exportovaly. I u nepatrne vetsich databazi trvaly exporty silene dlouho a pritom po nepatrne uprave retezcovych operatoru + a += za StringBuilder je urychleni znatelne na prvni pohled (hlavne to samozrejme oceni zakaznici ;-)

  • 13. 1. 2011 20:03

    kuka (neregistrovaný)

    Tak to jiste, ja urcite nijak neobhajuju spojovani retezcu operatorem +. Je s podivem, jak casto je to k videni, vezmeme-li v uvahu, ze to byva rozebirano tak na desate strance kazde ucebnice javy. Vzhledem k tomu, ze nastroje na kontrolu kodu uz dnes umeji vyskyt takovych veci detekovat, melo by se to asi v novem kodu uz vyskytovat spis vyjimecne. Jen jsem chtel upozornit, ze uz pouziti StringBuilderu je co do slozitosti oproti naivni implementaci takovym posunem, ze je jen zridka (cimz netvrdim ze nikdy) nutne pouzivat sofistikovanejsi reseni a ze ta se navic mohou v nekterych scenarich ukazat jako horsi.

  • 17. 1. 2011 3:02

    Maaartin (neregistrovaný)

    To ja bych to i obhajoval, muselo by to ovsem vypada takto

    public static String createString()
    {
    StringBuilder str = "";
    for (int i = 0; i < LOOP_COUNT; i++)
    {
    str += i + " ";
    }
    return str.toString();
    }

    Jak krasne prehledne a soucasne efektivne by se dalo psat, kdyby + a += fungovaly i pro StringBuilder. Byla by to si malickost udelat, kdyz uz se to udelalo pro String. Kdykoliv je lehci napsat horsi variantu, tak to dopada spatne.