Teszteltem több verziójú Firefox és Opera alatt, mindenhol jelentősen gyorsabb a mezei szöveg összefűzés. Van valakinek ezzel kapcsolatban tapasztalata, tanácsa?
lehet, hogy én értelmeztem rosszul ezt a korábbiakban, de nekem mindig az volt a benyomásom, hogy arról az esetről beszélnek, amikor már megvan a kész tömb, amit össze szeretnénk fűzni. Azaz
Ha már van egy tömbön, értelemszerűen a join()-t fogom használni, de azt a tömböt is egyszer fel kell tölteni, illetőleg a cikkben is az én példámmal gyakorlatilag egyező kódot mutatnak; két ciklus, nulláról kezdek, egyikben push()-sal töltök, másikban konkatenálok. Lehetséges, hogy itt valóban annyi a megjegyeznivaló, hogy már feltöltött tömb elemeit érdemes join()-nal összefűzni, de akkor nem látom, mi a másik út?
Ha már van egy tömbön, értelemszerűen a join()-t fogom használni
Te lehet, hogy igen, de nem vagy kellőképp reprezentatív minta :) Te sem lepődnél meg, ha valahol feltöltött tömbön is strconcat-et találnál :) De vissza a tárgyhoz: tegyük fel, te értelmezed jól (s a linkjeid alapján úgy tűnik, én voltam naív). A bookmarkolt oldal azt mondja, hogy:
This method will result in too many intermediate strings and concatenation operations, and will poorly perform overall.
Azaz az első megoldásban az lassít, hogy minden ciklusban kiolvassa az str értékét, hozzáfűzi az új értéket, majd letárolja az eredményt memóriaban, végül ezt átmásolja az str-be (vagy csak mutatót billent?), azaz így ciklusonként két vagy három új sztring jön létre, s ezen sztringek létrehozása (memória lefoglalása) okozza a gondot.
Ugyanakkor megjegyzi, hogy a tömbös megoldás
This method doesn't suffer from the extra string objects, and generally executes faster.
, mert ciklusonként csak egy sztring jön létre, amit a tömb változóban tárol el. Itt szvsz az lassít, hogy a tömböt folyton át kell méretezni. Ha fix méretű tömböt hozol létre, akkor is lassabb? S ha hosszabb sztringeket gyártasz, akkor mi az eredmény? Más böngészőkön mi az eredmény? Ezt még megnézzük...
Erősen függ a dolog attól, hogy mely JavaScript értelmező van a háttérben. A Firefox-é és az Operáé übermodern, ezeket ezekszerint megoldották benne. Próbáld ki Explorerrel is. Egyébként úgy tudom, hogy ez más nyelveknél is probléma tud lenni, nem JS specifikus.
Az array.push() megoldásnak van még egy előnye: kisebb a hibalehetőség. A string összefűzésnél gyakran előfordul, hogy "+=" helyett véletlenül sima "="-t írok.
Hogy célszerűbb sok szöveget egybefűzni?
Csak nálam nem?
arrayconcat: 159ms
arrayconcat2: 108ms
Teszteltem több verziójú Firefox és Opera alatt, mindenhol jelentősen gyorsabb a mezei szöveg összefűzés. Van valakinek ezzel kapcsolatban tapasztalata, tanácsa?
nem feltöltött tömbről beszélünk?
Mi a különbség?
join
()-t fogom használni, de azt a tömböt is egyszer fel kell tölteni, illetőleg a cikkben is az én példámmal gyakorlatilag egyező kódot mutatnak; két ciklus, nulláról kezdek, egyikbenpush()
-sal töltök, másikban konkatenálok. Lehetséges, hogy itt valóban annyi a megjegyeznivaló, hogy már feltöltött tömb elemeit érdemesjoin()
-nal összefűzni, de akkor nem látom, mi a másik út?arrconcat: 6ms
re: ha már van tömböm
Te lehet, hogy igen, de nem vagy kellőképp reprezentatív minta :) Te sem lepődnél meg, ha valahol feltöltött tömbön is strconcat-et találnál :) De vissza a tárgyhoz: tegyük fel, te értelmezed jól (s a linkjeid alapján úgy tűnik, én voltam naív). A bookmarkolt oldal azt mondja, hogy:
Azaz az első megoldásban az lassít, hogy minden ciklusban kiolvassa az str értékét, hozzáfűzi az új értéket, majd letárolja az eredményt memóriaban, végül ezt átmásolja az str-be (vagy csak mutatót billent?), azaz így ciklusonként két vagy három új sztring jön létre, s ezen sztringek létrehozása (memória lefoglalása) okozza a gondot.
Ugyanakkor megjegyzi, hogy a tömbös megoldás
Nincs kész a tömb
JavaScipt értelmező
Plusz
Sok hűhó
Kisebb hibalehetőség
assertion rész
Ez az assertionos rész hogy működik?
A try...catch(e) -ben az e az err objektum, hogy lesz instanceof AssertException?
Köszi...
KR