Hi Andreas, here's my 2nd (more detailed) reply:
> Hi Peter, > [...] >>>> [...] Wouldn't "Function" be the better choice? >>> >>> Why would it? There doesn't seem to be a real difference to me (except >>> regarding scoping, but this should be irrelevant here). >> >> I think it's a bit more than just scoping. As far as I remember the >> eval() call >> starts a complete new compiler, parser etc. pp. > > I fail to see how creating a Function object based on a string is > different? That was exactly what I was wondering myself. The question just raised when the tools complained about eval(). For the "broken tools" argument, see further down ;) I do believe that a new compiler/parser has to be invoked in both cases, when the parameter is a string object (a string literal might behave different). At that point I wondered..."why not ask the forum," ;) >> On the other hand it seems to me that "eval() is evil" is common sense >> throughout all developers ;) > > Why do you consider feeding a string to the Function constructor less evil? I don't. I just tried to exchange eval() by Function to keep the (broken) tools happy. Then I looked at the different browsers for incompatibility issues. After that I just looked at the performance differences, out of curiosity. More details on that further down. >>>> I've tried the following replacement in our application that works >>>> quite good >>>> (and is about 6 to 7 times faster!): >>> >>> Let me guess: You have Firebug enabled, right? As mentioned on this >>> list a short while ago, Firebug can _severely_ affect JavaScript >>> performance. >> >> Yes, and no. >> I've done my measurements with several Browsers and most of them do >> not even >> have a Firebug (Opera, IE, Chrome, Safari). Addendum: I checked those Browsers only for incompatibility issues. The performance "measurement" was done with Firebug. After re-running my tests (and yours as well) with and without Firebug and on different Browsers I can confirm the _severe_impact_ of Firebig on the eval()! Sorry for any inconvenience. Just keeping with the (german) slogan ''Wer misst, misst Mist!'' > Do you have a test page that you could share with us? I just created a > mini test page myself (see attachment), and eval() was as fast or even > faster than Function() (especially in Safari where, for whatever reason, > the Function() variant is really slow). My test was very close to yours, except that I run the creation in a loop to "measure" the average impact of the complete eval()/Function call. I set "measure" here in quotation marks due to the fact that my results were not very fair against eval() ;) Blame Firebug! :-D >> I agree, that performance is nothing easy to measure. And by the way, >> that was >> not my main concern (just a spin-off ;) ) > > In this case, performance _is_ my main concern because I still don't see > any other significant difference. Again, why do you think the Function() > way is any cleaner than eval()? Both take a string and compile and > execute it on the fly. Correct! After thinking and discussing the issue it seems to me that there really is no difference between the two approaches (at least in our case). And if eval() has just a slightly better performance, it should get the award. I personally will stay on with eval() in my case. Until someone can bring up some other serious charges against it ;) >>> For some more performance tests, take a look at this page: >>> >>> http://weblogs.asp.net/yuanjian/archive/2009/03/22/json-performance-comparison-of-eval-new-function-and-json.aspx >>> >>> >>> The Function approach takes about the same time as the eval() call >>> (with the exception of the Safari 4 beta where it's way slower - but I >>> guess this is fixed in the current Safari version). >>> >>> Please note that the results for Firefox in the first two tables seem >>> to indicate that Function() is way faster - but if you scroll down, >>> there is another table with Firebug turned off, and the results are >>> quite different! >> >> As mentioned, performance was not the main focus. I just followed the >> "eval() is evil" prayers... ;) > > If you look closer, you'll see that Function() with a string is just as > frowned upon. eval() is used in qooxdoo because there wasn't any usable > alternative until recently (and there's already an open bug for making > use of the new native JSON implementations). O.K. Really nice to hear. I'm not sure about any impacts on performance, but I like the idea. Another option might be to use the Browsers JSON Object if available, although they will definitely not support qooxdoos "Date-Object Transport", I think. >> As with most of the JavaScripts engine features, it seems to be that the >> performance issue of eval() is decreasing with every new browser version. > > I don't have this impression. Do you have any tests/references for this > assumption? Addendum: That sentence of mine was total rubbish! Just a typo. Replace "decreasing" by "increasing" and it makes a bit more sense (I hope) >> My main intention was to 'clean' my code so that most tools (e.g. >> jslint[1] or >> even qooxdoos own "lint") will not complain anymore. > > If the tools complain about eval() but not about Function() with a > string, the tools are broken :-) I agree! For qooxdoos 'lint' it might be nice to have some control comments to disable a warning at certain places. Although this feature might be present in the current qooxdoo release already. I still have to work with qooxdoo 0.7.x (which is still great, ...just a bit old) >> I will not start to list all the many "eval() is evil" pages around >> that google >> spits out when you ask 'em. But as far as I know it's still better, >> not to use >> eval()[2]. > > I agree that eval() should only be used when necessary. But your > proposed replacement is just as evil (and slower, according to my > measurements). I can currently not confirm your measurement on Safari, but all the other Browsers I've tried here show that there is almost no difference between eval() and Function. So I have the choice between two evil villains...Hmm...I take the faster one ;) > > Regards, > > Andreas J. Thanks a lot for sharing your research results, Peter ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
