Nothing fancy - All Comments

re: Firefox 3. XSLT Processing Engine bug?

Veacks — Tue, 08 Jul 2008 17:06:05 GMT

PS: the bug is in the transformation, not in javascript CODE.

I think there is something that firefox do not interpret any more, I dont kow what is it.

The other XSLs are Ok, thre is just one who dont work.

All have multi imports, it can't be the problem.

re: Firefox 3. XSLT Processing Engine bug?

Veacks — Tue, 08 Jul 2008 16:40:41 GMT

Hello AGZ, I also have a bug in XSL which did not exist in FireFox 2.

Did you found a solution or informations ?

re: Firefox 3. XSLT Processing Engine bug?

AGS777 — Fri, 04 Jul 2008 09:32:33 GMT

Egor,

Unfortunately the problem/solution referred to in your comment is completely irrelevant to the issue I indicated in the post.

The issue is not related to XSLT file path in any case and, as it is shown in the post, the processing does not fail, the problem actually is in the erroneous result of the processing.

Thanks for you reply though.

re: Firefox 3. XSLT Processing Engine bug?

Egor — Fri, 04 Jul 2008 07:00:35 GMT

This worked for me:

1) type about:config in the address bar

2) change security.fileuri.strict_origin_policy to false

Taken from

forums.mozillazine.org/viewtopic.php

net framework 1 1

net framework 1 1 — Mon, 19 May 2008 15:14:16 GMT

Pingback from net framework 1 1

re: Array.prototype.slice vs manual array creation

AGS777 — Sun, 18 May 2008 16:33:25 GMT

Isaac,

Yes, I know that premature optimization is the root of all evil in programming. But, as I wrote in the initial post on the subject, actually I wanted to use Array.prototype.slice to optimize existing code which is at the moment is implemented as a manual iteration through arguments object members. And it turned out, to my surprise, that there is no reason to do it, since there are no any tangible benefits other than forcing other members of our team to burn a few additional brain cycles to understand otherwise plain and simple code.

And yes, I tried, without any hope, to pass Array.prototype.slice as a parameter to the function. Nothing changed.

So, thank you once again for your replies, but to my mind we need someone with a knowledge of internal implementation of the method in major browsers to answer whether my expectations regarding performance of a native method had any grounds at all.

Best regards

re: Array.prototype.slice vs manual array creation

Isaac Z. Schlueter — Sun, 18 May 2008 01:38:28 GMT

That's interesting.

Looking up the global Array vs the global _slice should be about the same, so that makes sense. What about passing a reference to Array.prototype.slice directly to the function so that it's a parameter rather than a global var?

One way that Array.prototype.slice is better than iteration, though, is that it's less code. In general, the fewer instructions you have, the less chance there is for bugs to creep in, and the more clear and maintainable the code is. Early optimization is not usually a good idea, especially if it results in a less clean design.

re: .NET Framework 1.1 Service Pack 1 and Page.RegisterStartupScript

Joe — Sat, 17 May 2008 22:19:55 GMT

To be fair to MS, the documentation for RegisterScriptBlock does state that "The script blocks are not guaranteed to be output in the order they are registered.".

But I'd still define it as a bug (otherwise they wouldn't have fixed it) - it's worth remembering, thanks.

re: Array.prototype.slice vs manual array creation

AGS777 — Sat, 17 May 2008 19:55:12 GMT

Issac,

Thank you for your reply.

Are you sure that looking up global Array object and then looking up for its prototype property and then slice property of the prototype should be faster than looking up for the single global _slice variable?

In fact this statement was intended to avoid such look ups. And I've seen this exact declaration in Dean Edwards' Base2 library.

For what I can see from the test results (I tried to increase number of iterations and number of arguments) - replacement of _slice to Array.prototype.slice gives more often than not some increase in time for the second variant.

I've also tried to increase number of arguments further and changed the code so that the result of the call is saved as you suggested and got approximately the same results. I don not already have the same browsers that were used during my first tests. All of them (Firefox, Safari, Opera and even IE) released newer versions since then but as I said the result is pretty much the same, i.e. there is no any performance benefits in using slice vs manual iteration through arguments members as I expected.

Best regards

re: Array.prototype.slice vs manual array creation

Isaac Z. Schlueter — Sat, 17 May 2008 11:33:51 GMT

The reason why the slice method is slower in your example is probably because it's looking up the scope chain to find the global _slice object.

Either replace the reference to the global _slice with Array.prototype.slice inside the function, or pass the slice reference into the function as an argument. Scope chain lookups can be pretty slow.

Also, looping through only three elements isn't that much. Try generating an array of 1000 elements, and calling the functions with Function.apply, and then the difference may be more pronounced.

Lastly, I've found some cases where the browsers are optimized to discard values that are not set to be assigned anywhere. Instead of just calling fn(...), try doing var x = fn(...) so that it knows that it has to actually keep track of the return val.

Cheers!