• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

fadeIn Problem

"Hausrecht" liegt bei kkapsner
Ich hab' hier gar kein Hausrecht - das hätte mo.

im Speicher (!) dann Sub-Selects fahre.
Zeig' mir bitte den JS-Code, mit dem zu Sub-Selects fährst, ohne ins DOM zu greifen! Mehr will ich nicht.

Und auch DOM-Transversal ist langsamer als Zugriff über ID:
Code:
<!DOCTYPE html>

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Fenstertitel</title>

<style type="text/css"></style>
</head>
<body>
<script>
var fragment = document.createDocumentFragment();
for (var i = 0; i < 1000; i += 1){
	var d = document.createElement("div");
	d.id = "a" + i;
	d.innerHTML = "<a>test</a>" + "h".repeat(i);
	fragment.appendChild(d);
}
document.body.appendChild(fragment);
</script>

<div id="div1"><div id="div2">das hier will ich haben</div></div>

<script>
var fragment = document.createDocumentFragment();
for (var i = 0; i < 1000; i += 1){
	var d = document.createElement("div");
	d.id = "b" + i;
	d.innerHTML = "<a>test</a>" + "h".repeat(i);
	fragment.appendChild(d);
}
document.body.appendChild(fragment);
</script>

<script type="text/javascript">
var div1 = document.getElementById("div1");
function id(){
	var div = document.getElementById("div2");
	return div
}
function sub(){
	var div = div1.getElementsByTagName("div")[0];
	return div
}
function child(){
	var div = div1.childNodes[0];
	return div
}
function first(){
	var div = div1.firstChild;
	return div
}

var r = 1000000000;
window.setTimeout(function(){
	var t = Date.now();
	for (var i = 0; i < r; i += 1){
		id();
	}
	console.log("id: " + (Date.now() - t) / r * 1000 + "µs");
	r /= 100;
	window.setTimeout(function(){
		var t = Date.now();
		for (var i = 0; i < r; i += 1){
			sub();
		}
		console.log("sub: " + ((Date.now() - t)) / r * 1000 + "µs");
		
		window.setTimeout(function(){
			var t = Date.now();
			for (var i = 0; i < r; i += 1){
				child();
			}
			console.log("child: " + ((Date.now() - t)) / r * 1000 + "µs");
			
			window.setTimeout(function(){
				var t = Date.now();
				for (var i = 0; i < r; i += 1){
					first();
				}
				console.log("first: " + ((Date.now() - t)) / r * 1000 + "µs");
			}, 0);
	
		}, 0);
	
	}, 0);
}, 0);
</script>
</body>
</html>
Das DOM hat da ca. 13MB und das ist das Ergebnis:
id: 0.000619µs
sub: 0.1166µs
child: 0.0664µs
first: 0.0007µs

Es ist also alles langsamer als der Zugriff über die ID! Man optimiert also nicht, wenn man die ID-Zugriffe durch was-auch-immer ersetzt.

@mikdoe: nicht,dass ich wüsste.
 
Es ist also alles langsamer als der Zugriff über die ID! Man optimiert also nicht, wenn man die ID-Zugriffe durch was-auch-immer ersetzt.
das klingt unlogisch, hast du recht wenig ids gehabt? sobald mehr ids als zu durchsuchende propertys vorhanden sind, sollte die suche nach id nicht schneller sein, als die suche nach der property.
gut, firstChild ist ja auch schneller, aber das wäre schon zufall, wenn es gerade firstChild ist
gut, bei childNodes[idx] sind es 2 zugriffe erst muss childNodes gesucht werden, dann der arrayzugriff, aber gerade der arrayzugriff sollte wesentlich schneller sein als eine suche
könnte noch sein, du hast zufällig in der id-suche immer die 1. id erwischt

Zeig' mir bitte den JS-Code, mit dem zu Sub-Selects fährst, ohne ins DOM zu greifen! Mehr will ich nicht.
mit Sub-Selects meint er meiner meinung nach genau die begrenzte suche über die childs oder ähnliches und nicht die suche über die gesammte id-liste
 
das klingt unlogisch,
Genau deswegen hab' ich den Test gemacht. DOM-Zugriffe sind nicht immer logisch...
hast du recht wenig ids gehabt?
Schau' dir den Code an. Hatte 2002 IDs.
aber das wäre schon zufall, wenn es gerade firstChild ist
Stimmt - wollte es aber mit reinnehmen, damit man es vergleichen kann. Denke mal nextSibling und previousSibling sind ähnlich schnell.
könnte noch sein, du hast zufällig in der id-suche immer die 1. id erwischt
Würde mich jetzt wunder. Es werden 1001 IDs davor registriert und alphabetisch ist sie auch am Ende...

Aber so wie's aussieht, macht der Browser da eine Umsortierung. Eine häufig benutze ID wird schneller gefunden. Hab' den Test mal auf lauter verschiedene IDs laufen lassen:
Code:
<!DOCTYPE html>

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Fenstertitel</title>

<style type="text/css"></style>
</head>
<body>
<script>
var fragment = document.createDocumentFragment();
for (var i = 0; i < 100000; i += 1){
	var d = document.createElement("div");
	d.id = "a" + i;
	fragment.appendChild(d);
}
document.body.appendChild(fragment);
</script>

<script type="text/javascript">
var div1 = document.getElementsByTagName("div")[0];
function id(i){
	var div = document.getElementById("a" + (i>>0));
	return div
}
function sub(i){
	var div = document.body.getElementsByTagName("div")[i];
	return div
}
function next(){
	var div = div1.nextSibling;
	div1 = div;
	return div
}

var r = 100000;
window.setTimeout(function(){
	var t = Date.now();
	for (var i = 0; i < r; i += 1){
		id(i);
	}
	console.log("id: " + (Date.now() - t) / r * 1000 + "µs");
	window.setTimeout(function(){
		var t = Date.now();
		for (var i = 0; i < r; i += 1){
			sub(i);
		}
		console.log("sub: " + ((Date.now() - t)) / r * 1000 + "µs");
		
		window.setTimeout(function(){
			var t = Date.now();
			for (var i = 0; i < r; i += 1){
				next();
			}
			console.log("next: " + ((Date.now() - t)) / r * 1000 + "µs");
	
		}, 0);
	
	}, 0);
}, 0);
</script>
</body>
</html>
Und jetzt ist Im FF id() und sub() etwa gleich schnell:
id: 0.3µs
sub: 0.24000000000000002µs
next: 0.02µs"
Im Chrome ist id() hingegen um einiges langsamer:
id: 0.75µs
sub: 0.17µs
next: 0.02µs
Aber eigentlich sind die Zeiten auch vernachlässigbar - alles unter eine Microsekunde...

mit Sub-Selects meint er meiner meinung nach genau die begrenzte suche über die childs oder ähnliches und nicht die suche über die gesammte id-liste
Gut - aber auch damit "greift" man ins DOM...

@SteelWheel: meine Frage nach dem Code war ernst gemeint. Ich würde gerne wissen, wie du das machen würdest.
 
@SteelWheel: meine Frage nach dem Code war ernst gemeint. Ich würde gerne wissen, wie du das machen würdest.
Daher bat ich den TO oben bereits mehrfach um den im Browser gerenderten Source (ebenfalls ernst gemeint), da ich es weiterhin so verstehe, dass "reglog" der Node ist, der alle anderen unter sich hat; und ich vertrete die Meinung, dass ich - statt mehrfach ins DOM zu greifen - nur 1x #reglog abgreifen muss und damit autom. alle anderen Beteiligten habe (aka 1x DOM). Du greifst ja bspw. auch eher auf "form" bei einem Gesamtbedarf anstatt auf jeden einzeln, oder?! (lassen wir bitte jetzt Validierung außer Acht!) Und Du verwendest doch bestimmt auch eine Variable (möglichst nicht global ^^), wenn Du mehrfach auf $(this) in einem bspw. on()-Handler agierst, oder? Exakt dieses Prinzip - einfach mit dem Selector weiterarbeiten und - wenn möglich - höher abgreifen; erst recht bei der beschriebenen Anforderung ("ein unter reglog liegendes DIV soll gezeigt werden"; es wird u. U. nicht die einzige Operation im restlichen DOM sein).

Du benutzt oben übrigens genau den umgekehrten Ansatz mit "fragment" - nur ist es Dir gar nicht mehr so bewusst, warum Du das eigentlich machst (hättest genauso 100.000x direkt ins DOM schreiben können). Für den TO habe ich genau den Ansatz verfolgt - nur exakt umgekehrt: ein "Fragment" (Teilbereich) aus dem fertigen DOM nehmen und damit (!) (weiter-)arbeiten ... anstatt x Mal reinzulangen bei der beschriebenen Anforderung bzw. Problemstellung.

Und nochmal: Ich erhebe null Anspruch auf Gehör (Stichwort "Zeit vernachlässigbar"). Das Gesamtpaket entscheidet am Ende, ob es performant ist oder nicht - dann, wenn alle denkbaren Flaschenhälse zusammen kommen.
 
Du benutzt oben übrigens genau den umgekehrten Ansatz mit "fragment" - nur ist es Dir gar nicht mehr so bewusst, warum Du das eigentlich machst (hättest genauso 100.000x direkt ins DOM schreiben können). Für den TO habe ich genau den Ansatz verfolgt - nur exakt umgekehrt: ein "Fragment" (Teilbereich) aus dem fertigen DOM nehmen und damit (!) (weiter-)arbeiten ... anstatt x Mal reinzulangen bei der beschriebenen Anforderung bzw. Problemstellung.
100000 mal ins dom zu schreiben ist aber ein ECHTES Performanceproblem, da lohnt es sich..., nein, da MUSS man optimieren.
die beiden fälle kann man so aber überhaupt nicht vergleichen, das eine ist eine modifizierung des dom, das andere eine leseoperation.
die leseoperation ist zeitlich unkritisch, da nur das element gesucht werden muss
bei der modifizierung, hast du aber nicht nur die suche, wo modifiziert wird, sondern ab dieser stelle muss das dom neu durchgerechnet werden (bei JEDEM einfügen)
 
Vorweg: Mein Ausdruck scheint falsch - "Sub-Selects" nennt man anderswo "Sub-Queries" ("additional selector operations on a already wrapped set").

Ja, genau das ist es - ein Performanceproblem, wenn ich da so reinschreiben würde und der Browser jedes Mal wieder rendern darf. Gar keine Widerworte! Ich sagte auch nur, dass der Grund vom Ansatz her gleich ist. Damit Du eben - s. Anforderung - nicht (unnötig) wieder ins DOM musst ("nur gesucht werden muss" - wir reden hier von einem Mini-Teil (s. o.), welcher von der Logik her nicht 4x im DOM gesucht werden muss, wenn ein Abgreifen völlig ausreicht, um es in der Folge bearbeiten zu können) ...

Ziehen wir einen Schlussstrich, bitte! Aufgrund fünfstelliger DOM-Teile bin ich gar kein Freund von "jedes Mal wieder aufs Neue rein" - das empfinde ich bereits als "unperformant" (auch ganz ohne ms-Angabe).
 
Ich auch - war ja auch eigentlich nicht mein Problem.
Daher bat ich den TO oben bereits mehrfach um den im Browser gerenderten Source
Gut - dann geb' ich dir hald mal einen, an dem du dein Beispiel bauen kannst:
HTML:
<div id="div">
	<div></div>
	<div></div>
	<div></div>
	<div></div>
	<div>
		<table>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
			<tr>
				<td></td>
				<td>
					<span><a></a></span>
					<span><a></a></span>
					<span><a></a></span>
					<span><a></a></span>
					<span>
						<a id="das_will_ich_haben"></a>
					</span>
					<span><a></a></span>
					<span><a></a></span>
					<span><a></a></span>
					<span><a></a></span>
					<span><a></a></span>
				</td>
			</tr>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
			<tr><td></td><td></td></tr>
		</table>
	</div>
	<div></div>
	<div></div>
	<div></div>
	<div></div>
	<div></div>
</div>
- Man hat eine Referenz auf #div. Wie greifst du jetzt auf #das_will_ich_haben zu ohne ins DOM zu "greifen"? (Du darfst das HTML gerne um irgendwas erweitern.)

damit autom. alle anderen Beteiligten habe
Wie bekommst du die "automatisch"? Genau das möchte ich von dir wissen.
Und Du verwendest doch bestimmt auch eine Variable (möglichst nicht global ^^), wenn Du mehrfach auf $(this) in einem bspw. on()-Handler agierst, oder?
Klar - Variablen mit direkten Node-Referenzen sind das Beste, denn da musst du wirklich nicht ins DOM. HTMLCollections sind da schon was anders. Aber darum geht es mir auch gar nicht, sondern wie du die Refernzen beim ersten Mal "automatisch" bekommst.

Exakt dieses Prinzip - einfach mit dem Selector weiterarbeiten und - wenn möglich - höher abgreifen
Das ist ein ganz anderes Prinzip... wenn man mit dem Selektor weiterarbeitet, kann man den Baum, der durchsucht werden muss, verkleinern, aber ins DOM muss man trotzdem...

nur ist es Dir gar nicht mehr so bewusst, warum Du das eigentlich machst
Doch - das was mir sehr bewusst. Wie hesst schon schrieb - Schreibeoperationen sind viel langsamer.

ein "Fragment" (Teilbereich) aus dem fertigen DOM nehmen
Solange der Teilbereich noch im DOM verankert ist, ist er immer noch Teil des DOMs. Und wenn du dann dort "reingreifst", "greifst" du immer noch ins DOM.

Ich erhebe null Anspruch auf Gehör
Ich auch nicht. Und so langsam verstehe ich, was du meinst. Aber besser wäre noch Code.

da MUSS man optimieren.
Genau deswegen hab' ich's gemacht ;)

bin ich gar kein Freund von "jedes Mal wieder aufs Neue rein"
Da wiederspricht dir ja auch niemand. Die DOM-Zugriffe sollten minimiert werden. Nur ist ein Subselect auch ein DOM-Zugriff.
 
Zurück
Oben