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:
- A
Merkkijono
esine paikassa 0 - A
StringBuffer
esine paikassa 10 - 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ää, StringBuffer
S: 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
.
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.