ugrás a tartalomhoz

Teljesítménymérés

Karvaly84 · 2011. Nov. 29. (K), 16.06
Helló guruk!

JavaScript-es fejlesztéssel kapcsolatban lenne egy kérdésem:

Egy olyan alkalmazást keresek ami pluginként vagy külön alkalmazásként, tudja mérni egy adott oldalon azt, hogy a JS feldolgozó egység mennyi memóriát emészt fel munka közben/után(szemét, closure, stb), illetve menyi idő alatt fut le, és mekkora processzor terhelést generál ez mellé. Létezik ilyen, amivel az összes böngészőn tudok egy tesztet csinálni?
‹ CSS vagy Javascript hiba Bejegyzés keret ›
 ■
1

nem hiszem

Poetro · 2011. Nov. 29. (K), 16.19
Mivel böngészőben futó JavaScript-ből nem férsz hozzá a közvetlenül a memóriához, ezért nem hiszem hogy létezne ilyen. Maximum valamilyen plugin formájában. Viszont plugin keresésére minden böngészőnek megvannak a saját eszközök, érdemes azokat használni.
2

profiler

H.Z. v2 · 2011. Nov. 29. (K), 16.42
Ha rákeresel a javascript profiler kifejezésre, az nem segít? (csak hirtelen jött ötlet)
4

nem tudtam angolul

Karvaly84 · 2011. Nov. 29. (K), 20.37
nem tudtam angolul megfogalmazni, és köszönöm :)
6

Sajnos itt én is elakadtam,

H.Z. v2 · 2011. Nov. 29. (K), 21.13
Sajnos itt én is elakadtam, mert csak a firebugot néztem meg alaposabban, de az a memória használatával kapcsolatos infókat elég alaposan elrejti a kíváncsiskodók elől. ;)

Mondjuk nem is tiszta teljesen, hogy mit is akarsz a memóriával, mert - amennyire tudom - a JS szemétgyűjtője még annyira sem hozzáférhető, mint a java-é, egyéb módon meg nem nagyon tudod befolyásolni a memóriahasználatot (hacsak nem használsz dinamikusan növekvő tömböket), szóval sok értelmét én nem látom. Persze ez lehet, hogy csak a tudatlanságom miatt van.
7

példa

Karvaly84 · 2011. Nov. 29. (K), 21.32
v1:

Function.prototype.extend = function(proto) {
	proto = proto || {};
	var Chain = function() {};
	var Class = proto.hasOwnProperty('constructor') ? proto.constructor : proto.constructor = function() {};
	Chain.prototype = this.prototype;
	Class.prototype = new Chain();
	for (var k in proto) Class.prototype[k] = proto[k];
	return Class;
};
v2:

Function.prototype.extend = function(proto) {
	proto = proto || {};
	var Chain = function() {};
	var Class = function() {
		return proto.constructor.apply(this, arguments);
	};
	Chain.prototype = this.prototype;
	Class.prototype = new Chain();
	for (var k in proto) Class.prototype[k] = proto[k];
	return Class.prototype.constructor = Class;
};
Ez a legelső amivel kezdeném, de nem tudom a 2. verzió mennyire lassít egy olyan rendszerben ahol sok az öröklődés, és mennyivel foglal több memóriát a closure miatt. Végül is az elsőt még le tudom mérni javascriptel is akár, de a második kérdést nem tudom hogy vizsgáljam.
8

Probléma

Poetro · 2011. Nov. 29. (K), 21.55
Amíg nincs memória probléma addig nem érdemes rá optimalizálni.
Premature optimization is the root of all evil

Donald Knuth - Structured Programming with go to Statements

Majd ha észleled, hogy huzamosabb használat után elkezd valahol szivárogni a memória, na akkor érdemes rá odafigyelni. Azt pedig, hogy melyik gyorsabb, elég egyszerűen le lehet mérni, van rá számos eszköz, például a jsPerf.
9

Azért ez mégiscsak

H.Z. v2 · 2011. Nov. 29. (K), 21.58
Azért ez mégiscsak strukturált programozásról szól, nem OOP... ;-)
Egyébként üzemeltetői oldalról én kicsit másképp láttam a dolgot. Mert ennek az optimalizálás nélküli fejlesztésnek(*) általában az volt a következménye, hogy ott a rendszergazda/DBA, csináljon valamit! És általában az derült ki, hogy a mi oldalunkon esélytelen, a programot kell...

* - igen, tudom, hogy ez nem arról szól, hogy optimalizálatlan programot adj ki a kezedből, de a vége többnyire az volt, hogy fontosabb volt minden más, végül a határidők miatt az optimalizációt kiváltották az erősebb hardverrel...
12

"Azért ez mégiscsak

Leonuh · 2011. Nov. 29. (K), 22.10
"Azért ez mégiscsak strukturált programozásról szól, nem OOP... ;-)"

Ezt azert ne hireszteld ebbe a formaba... Nem szallok vitaba de ennyit mondok... kulcsszavak: "extjs4 mvc"

*de az allitas fele mindenesetre igaz, nehez tema :)
13

Jó, végülis a JS egy

H.Z. v2 · 2011. Nov. 29. (K), 22.15
Jó, végülis a JS egy szörnyszülött, ha úgy vesszük. :-)
15

de imadom :D:D:D a maga kis

Leonuh · 2011. Nov. 29. (K), 22.39
de imadom :D:D:D a maga kis betegsegeivel
11

Megeloztel a picsaba :D

Leonuh · 2011. Nov. 29. (K), 22.00
Megeloztel a picsaba :D
10

A memoria hasznalata

Leonuh · 2011. Nov. 29. (K), 21.59
A memoria hasznalata masodlagos, ami elsodleges azt itt tesztelheted: http://jsperf.com/

for in-t nem hasznalunk... mivel sokkal lassubb mint while ... a while pedig lasubb mint a sima for...

De az otlet jo :)
14

for in-t nem indexértékek

Karvaly84 · 2011. Nov. 29. (K), 22.23
for in-t nem indexértékek másolására használtam hanem név-érték párokra, vagy erre használható lenne a tömböknél megszokott for vagy while? Most össze zavartál...
16

http://jsperf.com/for-in-vs-f

Leonuh · 2011. Nov. 29. (K), 22.52
http://jsperf.com/for-in-vs-foreach/7

forEach ott ahol tamogatva van/ gracefull fallback kell for in-re :)
17

Most vagy én vagyok tök

Karvaly84 · 2011. Nov. 29. (K), 23.31
Most vagy én vagyok tök hülye, vagy nem olvastad el azt a kis példát amit beszúrtam, ugyanis a példámban a for in-t egy sima Object példányon futtatnám, nem egy Array példányon.
18

Elnezest a felrevezetesert,

Leonuh · 2011. Nov. 30. (Sze), 01.37
Elnezest a felrevezetesert, felejtsd el amit irogattam utobb.... nagyon este van... (a lenyege volt hogy ahol lehet keruljuk a for int :), a te esetedben sajnos nem lehetett kikerulni)

Megmutatom hogy lehet 90%os sebessegnovekedest is elerni:

Csinaltam egy kis sebessegtesztet -> Asszociativ tomb kezeles mas modon :) (persze a(z) objektumot/tombot maskepp kell osszeallitani)

http://jsperf.com/forin-vs-for

(Ez csak egy elmeleti pelda a for in tokeletes a te peldadban... csak hogy lasd hogy a for in mennyire rosszul van megirva :/ , mert ugye atirni mindent nagyon nagyon sok lenne kodban is es sajnos ilyenkor merlegelni kell :) )
3

Chrome alatt

Poetro · 2011. Nov. 29. (K), 17.59
Chrome alatt több eszköz van a teljesítmény mérésére. Az egyik a beépített Fejlesztői eszközök, a másik a szintén beépített Feladatkezelő, és a telepíthető Speed Tracer kiegészítő.

A Feladatkezelővel figyelheted a memóriát, mind a fül által összesen, mind pusztán a JavaScript által használt memóriát. Remélem nem fogsz meglepődni, amikor megnézel egy Google Docs oldalt, és megnézed mennyi memóriát eszik csak JavaScript-ből.

A Fejlesztői eszközök rengeteg eszközt nyújt a teljesítmény mérésére, bár ez inkább klasszikus értelemben vett profiler feladatokat lát el, memóriáról nem szól.

A Speed Tracer pedig egy, a Fejlesztői eszközöknél átfogóbb profiler, igazából mutatja, a futás során mi történt, és az mennyi ideig tartott.

Internet Explorer alatt az F12 fejlesztői eszközök alatt férsz hozzá profiler adatokhoz, de ez szintén nem ad semmilyen képet a memóriáról, csak a futási időkről. Ugyanez a helyzet a Firefox-os Firebug esetén is.
5

Ez a Speed Tracer jónak

Karvaly84 · 2011. Nov. 29. (K), 20.44
Ez a Speed Tracer jónak ígérkezik, máris utána nézek, egyébként ja sejtem hogy egy google alkalmazás zabál mint a disznyó, pl pont ilyen dolgok miatt keresem a fent említett eszközöket, mert egy olyan kis kódtáron dolgozok amivel kisebb projekteket tudok csinálni, és olvastam hogy pl az Ext Js amivel elég jól működő osztályokat lehet gyártani nagyon lassít ha sok osztályt terjesztek ki, és most fogom elkezdeni, több ötletem van a kivitelezésre de mindet ki akarom próbálni, melyik a leggyorsabb, és melyik eszik keveset a ramból.