#43 comment_or_quote optimalization

[Ron]

Instead of using regular expressions it is much faster to just use string-functions. I've re-written the comment_or_quota function which is called many times when parsing highlighting code:

// determine if the selected text if a comment or a quoted text
EditArea.prototype.comment_or_quote= function(){
var new_class=false, close_tag="", sy, arg, i;
sy = parent.editAreaLoader.syntax[editArea.current_code_lang];
arg = EditArea.prototype.comment_or_quote.arguments[0];

for( i in sy["quotes"] ){
if(arg[0] == i){
new_class="quotesmarks";
close_tag=sy["quotes"][i];
}
}
if(!new_class)
{
for(var i in sy["comments"]){
if( arg[0] == i ){
new_class="comments";
close_tag=sy["comments"][i];
}
}
}
// for single line comment the \n must not be included in the span tags
if(close_tag=="\n"){
return "µ__"+ new_class +"__µ"+ arg.replace(/(\r?\n)?$/m, "µ_END_µ$1");
}else{
// the closing tag must be set only if the comment or quotes is closed
//reg= new RegExp(parent.editAreaLoader.get_escaped_regexp(close_tag)+"$", "m");
if( arg.substr(-1) == close_tag )
return "µ__"+ new_class +"__µ"+ arg +"µ_END_µ";
else
return "µ__"+ new_class +"__µ"+ arg;
}
};

[Ron]

.substr is not browser compatible, please change it to:

if( arg.substring(arg.length-1) == close_tag )

[Spellcoder]

I tried it in Firefox 3 with large Javascript files but with this patch it seemed alot slower there. Even up to the point a 2000 lines js file would make Firefox display it's dreaded dialog asking if you want to stop the script hanging this website.

Could you tell us for which browsers this speeds up the parsing? Maybe it's benificial for certain browsers...

[Nobody/Anonymous]

Hmm that's weird. I use this code under FF 3.0.10 with files around 1000 lines. Maybe there is some bug in my code? Or maybe the hanging is caused by something else?

It would be really awful if str[0] would take longer then executing a regular expression..?

[Ron]

Did you check if the special characters µ are stored properly with the right character encoding?

[Toff]

Well as this feature has been tested by pixelchutes and doesn't seems to add optimisation, I won't include it

[Ron]

As you can read from the comments spellcoder probably copied the code without the right encoding which broke the special µ character, and that's what causing his dialog window. In fact the only thing this patch does is:

replace: arg.indexOf(i)==0
with: arg[0] == i

If you think about this, then the behaviour is exactly the same. Furthermore, if you think about this, it can only be faster, slower isn't a option. Assume that arg is a string of about 20 characters, then indexOf will search this string for a occurance of i. In the optimization case, the first character of the string will be subtracted directly and compared with i. Which is much faster then first searching the complete string...