Új hozzászólás Aktív témák

• #4243 modder aktív tag MrSealRD #4239

  Új Válasz 2013-09-10 19:09:07 #4243

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  modder

  aktív tag

  válasz MrSealRD #4239 üzenetére

  Esküszöm, nem értem, mit akarsz mondani Superhun válaszára.

  De pár tény:
  1) A JVM k*rva okos és tele van optimalizációval. Memória allokációnak alig van költsége, persze sok kis objektum lassíthatja a GC-t. Megoldás: arra az objektumra ne veszítsük el a referenciát, amit újra fogunk használni. Ennek megkönnyítésére szoktak memory poolokat implementálni Javában úgy, ahogy C++-ban is. De ezeket elég speckó esetekben szokták használni, amikor a sebesség van mindenek felett.
  2) literálokra referencia mindig ugyanarra a memóriaterületre mutat. for() { String s = "nyorr"; } nem fog új objektumot létrehozni minden egyes iterációban
  3) Olyan mikro-optimalizációról beszélünk, aminél egy adatbázis lekérdezés nagyságrendekkel lassabb: semmi értelme gondolkodni rajta

  Ciklusban String összefűzést StringBuilderrel, mert azt a compiler tudtommal nem ismeri fel, ellenben a "egy" + "ketto" + $valami.toString; kóddal, amit StringBuilderre cserél (vagy StringBuffer, most hirtelen nem emlékszem, melyik a thread-safe)

  Nem látom értelmét String helyett StringBufferben tárolni a stringet.

  Szerk.:
  Közben rájöttem, mit akartál mondani, de elég veszélyes. Ha Stringbuilderben tárolod a stringeket, akkor a StringBuilder mutable, és olyan helyen is megváltoztathatod a String értékét, ahol nem akarod. pl.:

  StringBuilder strTime = getTimeInString();
  page1.setLastVisited(strTime);

  majd később:
  StringBuilder strTime = getTimeInString();
  page2.setLastVisited(strTime);

  no shit, lastVisited szintén frissült page1-re, mert ugyanaz az objektum. Nem hiába találták ki, hogy a String immutable.

Új hozzászólás Aktív témák