View Full Version : faster createElement() "Advanced"

12-02-2009, 07:44 PM
:) :) :)

rnd me
12-02-2009, 08:03 PM
you can make one and cloneNode(true) it, but you would still need to re-bind the events.

you can shorter syntax:

could be

(an empty onmouseover property won't hurt anything)

12-02-2009, 08:05 PM
I don't think the ifs are especially slow.

You could pass attributes as the {name:value}s of an object and loop through it-
this example will either create a new element or edit an existing one.

document.make= function(what, pa, atts){
if(what) what= document.createElement(what);
else what= pa;
var tem;
for(var p in atts){
tem= atts[p];
case 'style':
for(var c in tem){
what.style[c]= tem[c];
case 'text':
default: what[p]= tem;
if(pa && what!= pa) pa.appendChild(what);
return what;

12-02-2009, 08:11 PM
:) :) :)

rnd me
12-02-2009, 08:19 PM
Hmmmm, no I don't want to change to a switch case. I dont want to create uneeded attributes either, which is why I was using (if)s. I use this function alot to add new elements into a very dynamic animation and was hoping for something considerably faster.

Any other ideas? I am trying to minimize string manipulation and object creation processing. I am in heavy optimization mode.


cloneNode'ing a template element didn't help?

12-02-2009, 08:25 PM
:) :) :)

rnd me
12-02-2009, 08:37 PM
no it didn't...and I have to change so many of the existing property types that it is about the same, maybe a little slower.

It's (create with properties) VS. (clone and change properties). Some properties wont be there at all on the cloned elements, some will be different. The extra to remove unwanted cloned properties is killing its speed.

build a cached cloner, or clone the closest existing match rather than starting from scratch.

i've also see something i couldn't believe (at the time) worked; using an element as a generic object's .prototype to inherit default props to that object. might try something silly like that.

avoid manipulating dom properties at all costs.
if something is very complicated and you need lots of clones, it MIGHT be quicker to string-build and realize the actual elms via .innerHTML on a wrapper.

i would be willing to bet $0.50 or so that parsing 10,000 attrib-loaded elms via .innerHTML is faster than createElemement, but that's just a hunch...

12-02-2009, 08:53 PM
No. Forgive me DTD13, but the hat you try to wear is too big for you at the moment. Probably too big for any of us, at the moment. It is not your fault, it is the long list of differences between browsers which makes a cross-browser universal function quite difficult.

The first mistake is that you use innerHTML (which is not a standard DOM method) along with DOM method createElement(). If your argument mHtml bears a HTML code like a TABLE or TABLE's element (row, cell, ...) you will encounter an error. Microsoft warns that innerHTML is a read only method in case of a long list of tags. TABLE, TBODY, TR, TD, along with many others.

If you want only to insert text, then use createTextNode() method. It is crossbrowser.

Another one: cssText - it is read only in Mozilla. You need a crossbrowser workaround

What about other attributes which doucment's elements might need, other than CSS is able to create. What about readOnly (where IE needs that camel case), what about colSpan, disabled, what about a distinction between CSS and HTML attributes?

How do you expect to send a certain function via the mOut, mOver, mDwn arguments? As strings? Are you to use the clumsy eval() to restore the true meaning of those strings? With what cost? And have you an idea of how many event are there in JavaScript? Are you to use m+smt for some dozens of possible events?

No way, Sir, at least not on the way you have chosen. At least don't try to create an universal function. Be modest. Make 2 or 3 different functions: one to create (+- append) the elements, one to set the attributes (but make a distinction between CSS and HTML attributes) and one to attach the events (IE and Moz have different models to attach the events).

Still you will have some other bugs or strange behaviours to bypass. Good luck! :):thumbsup::thumbsup:

And this is only the visible top of the differences' iceberg :)

12-02-2009, 08:53 PM
Its not creatElement that is slow, it is when you append the element to the document,
or change the display on the page with a style or class name change, or write new content to it.

With either innerHTML or create element, the best outcome would be from assembling
as much as possible outside the document tree, either in a documentFragment or
an html string, and add them all at once.

At a minimum, don't add your spans and then apply changes to them, add them when they are complete.

12-02-2009, 08:54 PM
:) :) :)

12-02-2009, 09:10 PM
:) :) :)

12-02-2009, 09:28 PM
My method assumes that I can create any element with any property that I want.
I doubt. Try creating a cell with a colspan attribute and append it to a table. Furthermore, give it an id and try to change it afterward (in IE).

Or, try to create an INPUT element and try to give it a name attribute. Try to submit data from that INPUT (in IE). You will encounter a surprise. IE is not able to create the name attribute for new created elements, at least not in a standard DOM way.

Son, there are about another million of tricks/bugs/errors you have to find out and by pass :)

12-02-2009, 10:46 PM
:) :) :)

rnd me
12-03-2009, 12:01 AM
Anything wrong with that code Kor? Oh yes, no "world.get@assHolesByTagName()" exists. Such a large scope is prolly why and so many @assHoles. Perhaps some optimization techniques?

If Kor is so bad, why lower yourself to his level?

Not to be as rude as your last post, but I don't see 10 years of experiance reflected by your posts, (an 11-argument function???), but i'll give you the benefit of the doubt since it doesn't really matter.

In general, you may be Brendan Eich's personal mentor, but around here, expect to be judged by your thread/thank count, for better or for worse.
As far as Kor or I can tell, you're just a noob until proven otherwise.

BTW: you are almost assuredly wasting time by optimizing strings.
your app is bottle-necked by the DOM, not by native javascript operations...

It's not a scope problem, it's an in-dom vs off-dom issue.
Do as much as possible before inserting/appending, since in-tree node operations are slow.

Be kind; everyone you meet is fighting a hard battle.

12-03-2009, 01:05 AM
:) :) :)

Old Pedant
12-03-2009, 01:09 AM
Not to mention that Kor has the power to kick him off and make all his posts disappear.

If you're going to flame somebody, flaming the moderator isn't the wisest choice.

(And, actually, there are a couple of things wrong with the code. Spelling/grammar, for one. And why return a value from a function that is invoked via onload? <grin/>)

Edit: Oops. Teach me to take so long to post. <grin style="double"/>

12-03-2009, 01:29 AM
Right, well after trying to help some other real "noobs" I ran across another post by "Kor" he was much more rude to that person. I'm def not a "noob".
was more rude then you in response to his "son"?

best regards

12-03-2009, 02:00 AM
:) :) :)

rnd me
12-03-2009, 03:01 AM
That might work...and let me ask you this...if I did that would the clones, once appended, would they cause the same amount of redraw? If I could do in a way that eliminates redraw that would be awesome too.

yes, clones would invoke redraw.
here's a workaround:

//do stuff ...

hidden elms keep layout, but don't typically toggle reflow, sparing you a lot of CPU waste...

for pure coding ease and maintainability, i would consider passing an object instead of a dozen arguments. It's hard to remeber if the mouseover is the 7th or 9th argument...

You can merge with an existing template object, or set an existing object as the prototype of the new one, inheriting the defaults to the object you pass newElm.

var o = newElm("span","","window"+ numIdent,"window"+ numIdent,"","","","","","","");
could then be:

var o= newElm({objType:"span", obj:"window"+ numIdent , className:"window"+ numIdent });
which, imho is a lot more readable.

you might be able to get a bit of speed out of it as well, though it's likely negligible.

classes are also faster than .style, not sure how your doing that...

12-03-2009, 11:05 AM
I'm in the wrong place.
Possible :rolleyes:

DTD13, you are amazingly stubborn. We are here 3 or 4 coders, good coders I dare to say, who try to drive you toward a proper and logical direction. You show us a code and ask for optimization. We are telling you that code lays somehow on flimsy basis and you should rather think otherwise, but you keep coming back to that code. You have a single yet fixed idea. If so, why do you need us?

I don't believe people who, unprovoked, make a show of their experience. If you are an experienced coder you should have proved a well structured code, not an improvisation. It looks like you forgot (in case you have ever heard about) the basic principles of object-oriented analysis and programming.

But why do I worry about you? Murphy was right: "Never try to teach a pig to sing. It only wastes your time and annoys the pig"

12-03-2009, 01:11 PM
:) :) :)

12-03-2009, 02:37 PM
OK, I see. Now, what else can we do for you? It seems like you have given yourself all the answers to your own questions. Your method still looks a little bit questionable, if you ask me, but if you say it works, then in works. De gustibus non est disputandum and there are more than a single method to skin a cat, I agree.

IE gives you troubles? No news. Won't be for the first time when IE do that.

It is hard to say how could you optimize it. Probably you should give us the whole picture of your job, maybe there is something to optimize in the conception of your application, not in the code. You could try to reduce the number of globals as much as you can and to "kill" (give them a null value) the unnecessary reference as long as you don't need them. Probably you could reanalyze your closures in order to avoid the well known IE's memory leaks (I suppose you know the famous article of Douglas Crockford on the issue)...

Tell us what is all about your application.

12-03-2009, 03:01 PM
:) :) :)

12-03-2009, 03:10 PM
In the future, if you don't see any solution then don't speak.
Hey. I am perfectly entitled to speak whenever I want; as a Moderator, this Forum is my home, remember? I tried to ignore your insolence so far, but I guess I have to remind you that you are here not to judge the others, you are here to be judged, because you asked for help in this thread, not me.

OK. Let's stop the quarrel here. It has no future. We will analyze all you have told us about your project and if we might have an idea, we will post it.

It will be great if you could show us a link to a test page.

12-03-2009, 03:16 PM
:) :) :)

12-03-2009, 03:25 PM
Some pics will be ok, I reckon... For me, I feel the need to sense your application in terms of graphics, as well.

12-03-2009, 03:55 PM
:) :) :)

12-03-2009, 04:01 PM
:) :) :) :)