Ohjelmointi

StringBuffer vs. String

Java tarjoaa StringBuffer ja Merkkijono luokat ja Merkkijono luokkaa käytetään manipuloimaan merkkijonoja, joita ei voi muuttaa. Yksinkertaisesti sanottuna tyypin kohteet Merkkijono ovat vain lukukelpoisia ja muuttumattomia. StringBuffer luokan käytetään edustamaan merkkejä, joita voidaan muokata.

Näiden kahden luokan merkittävä suorituskykyero on StringBuffer on nopeampi kuin Merkkijono kun suoritetaan yksinkertaisia ​​ketjutuksia. Sisään Merkkijono manipulointikoodi, merkkijonot ketjutetaan rutiininomaisesti. Käyttämällä Merkkijono luokassa ketjutus suoritetaan tyypillisesti seuraavasti:

 String str = uusi merkkijono ("Stanford"); str + = "Kadonnut !!"; 

Jos haluat käyttää StringBuffer saman ketjutuksen suorittamiseksi tarvitset koodia, joka näyttää tältä:

 StringBuffer str = uusi StringBuffer ("Stanford"); str.append ("Kadonnut !!"); 

Kehittäjät olettavat yleensä, että yllä oleva ensimmäinen esimerkki on tehokkaampi, koska heidän mielestään toinen esimerkki, joka käyttää liitä ketjutusmenetelmä, on kalliimpi kuin ensimmäinen esimerkki, jossa käytetään + operaattori liittää kaksi Merkkijono esineitä.

+ operaattori näyttää syyttömältä, mutta luotu koodi tuottaa joitain yllätyksiä. Käyttää StringBuffer ketjutukseen voi itse asiassa tuottaa koodin, joka on huomattavasti nopeampi kuin a: n käyttö Merkkijono. Selvittääksemme miksi näin on, meidän on tutkittava luotu tavukoodi kahdesta esimerkistämme. Esimerkin tavukoodi käyttäen Merkkijono näyttää tältä:

0 uusi # 7 3 dup 4 ldc # 2 6 invokespecial # 12 9 astore_1 10 uusi # 8 13 dup 14 aload_1 15 invokestatic # 23 18 invokespecial # 13 21 ldc # 1 23 invokevirtual # 15 26 invokevirtual # 22 29 astore_1 

Tavukoodi paikoissa 0-9 suoritetaan koodin ensimmäiselle riville, nimittäin:

 String str = uusi merkkijono ("Stanford"); 

Sitten tavukoodi kohdissa 10 - 29 suoritetaan ketjutukselle:

 str + = "Kadonnut !!"; 

Asiat tulevat mielenkiintoisiksi täällä. Liitokselle muodostettu tavukoodi luo StringBuffer esine, sitten kutsuu sen liitä menetelmä: väliaikainen StringBuffer kohde luodaan sijaintiin 10, ja sen liitä menetelmää kutsutaan sijainnissa 23. Koska Merkkijono luokka on muuttumaton, a StringBuffer on käytettävä ketjutukseen.

Kun ketjutus on suoritettu StringBuffer esine, se on muunnettava takaisin a Merkkijono. Tämä tehdään puhelun kanssa merkkijono menetelmä paikassa 26. Tämä menetelmä luo uuden Merkkijono esine väliaikaisesta StringBuffer esine. Tämän väliaikaisen luominen StringBuffer esine ja sen myöhempi muuntaminen takaisin a Merkkijono esine ovat erittäin kalliita.

Yhteenvetona voidaan todeta, että yllä olevat kaksi koodiriviä tuottavat kolme objektia:

  1. A Merkkijono esine paikassa 0
  2. A StringBuffer esine paikassa 10
  3. A Merkkijono esine paikassa 26

Tarkastellaan nyt esimerkin avulla luotua tavukoodia StringBuffer:

0 uusi # 8 3 dup 4 ldc # 2 6 invokespecial # 13 9 astore_1 10 aload_1 11 ldc # 1 13 invokevirtual # 15 16 pop 

Tavukoodi paikoissa 0–9 suoritetaan koodin ensimmäiselle riville:

 StringBuffer str = uusi StringBuffer ("Stanford"); 

Tavun koodaus paikassa 10-16 suoritetaan sitten ketjutusta varten:

 str.append ("Kadonnut !!"); 

Huomaa, että kuten ensimmäisessä esimerkissä, tämä koodi kutsuu liitä menetelmä a StringBuffer esine. Toisin kuin ensimmäisessä esimerkissä, väliaikaista ei kuitenkaan tarvitse luoda StringBuffer ja muunna se sitten a: ksi Merkkijono esine. Tämä koodi luo vain yhden objektin, StringBuffer, paikassa 0.

Tiivistettynä, StringBuffer ketjutus on huomattavasti nopeampi kuin Merkkijono ketjutus. On selvää, StringBufferS: itä tulisi käyttää tämän tyyppisessä toiminnassa aina kun mahdollista. Jos Merkkijono luokka on toivottava, harkitse a StringBuffer ketjutukseen ja sitten yhden muunnoksen suorittamiseen Merkkijono.

Reggie Hutcherson on Sun-teknologian evankelistaja. Hän evankelioi Sunin Java 2 Platform -teknologioita ympäri maailmaa keskittymällä J2SE: hen ja HotSpot-suorituskykyyn.

Lisätietoja tästä aiheesta

  • "JavaWorld esittelee uuden viikoittaisen Java-suorituskykysarakkeen "Reggie Hutcherson (JavaWorld, Maaliskuu 2000)

    //www.javaworld.com/jw-03-2000/jw-03-javaperf.html

  • "Java-suorituskyvyn perusteet", Reggie Hutcherson (JavaWorld, Maaliskuu 2000)

    //www.javaworld.com/jw-03-2000/jw-03-javaperf_2.html

  • "Suorituskykyongelma tai suunnitteluongelma?" Reggie Hutcherson (JavaWorld, Maaliskuu 2000)

    //www.javaworld.com/jw-03-2000/jw-03-javaperf_3.html

  • "Kääntäjän optimoinnit", Reggie Hutcherson (JavaWorld, Maaliskuu 2000)

    //www.javaworld.com/jw-03-2000/jw-03-javaperf_4.html

Tämän tarinan "StringBuffer versus String" julkaisi alun perin JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found