<div id="reply-content"><span class="Apple-style-span" style="color: rgb(160, 160, 168); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On Monday, June 24, 2013 at 4:19 PM, Dieter Adriaenssens wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<div id="quoted-message-content"><div><div>2013/6/22 Mohamed Ashraf <mohamed.ashraf.213@gmail.com>:</div><blockquote type="cite"><div><div>On Sat, Jun 22, 2013 at 10:27 AM, Rouslan Placella <rouslan@placella.com> wrote:</div><blockquote type="cite"><div><div>On 06/22/2013 01:21 AM, Mohamed Ashraf wrote:</div><blockquote type="cite"><div><div>On Saturday, June 22, 2013 at 12:49 AM, Rouslan Placella wrote:</div><blockquote type="cite"><div><div>On 06/16/2013 12:59 PM, Mohamed Ashraf wrote:</div><blockquote type="cite"><div><div>On Wed, Jun 12, 2013 at 9:58 AM, Rouslan Placella</div><div><rouslan@placella.com> wrote:</div><div><br></div><blockquote type="cite"><div><div>Some of my thoughts are:</div><div><br></div><div>* Try/catch has a performance penalty</div></div></blockquote><div>it is not too big as can be seen here</div><div>http://jsperf.com/try-catch-performance-overhead</div></div></blockquote><div><br></div><div>Really? On some browsers it's about 20 times slower on the very</div><div>benchmark that you are linking to!</div></div></blockquote><div>Really!! That is strange I tested it multiple times and everytime it</div><div>showed they are all equal in time. Which test case was 20 times slower?</div></div></blockquote><div><br></div><div>Opera 11 would be one of them. IE 10 is also quite bad, but by a lower</div><div>magnitude...</div></div></blockquote><div><br></div><div>the reduction in performance is usually in wrapping the inside of a</div><div>function with try and catch. I was thinking of doing the other way and</div><div>wrapping the functions from outside like this</div><div><br></div><div>var temp = PMA_foo</div><div>PMA_foo = function() {</div><div>try{</div><div>temp.apply(window, arguments);</div><div>} catch(e) {</div><div>my_method(e);</div><div>}</div><div>}</div><div><br></div><div>I am thinking of doing this to all global functions starting with PMA_</div><div>and according to the benchmark this should have an equivalent</div><div>performance to the no try catch performance. also if we don't do</div><div>anything of the sort then we would never get a stacktrace.</div></div></blockquote><div><br></div><div>Just wondering, if you add try-catch phrases to the current PMA_*</div><div>functions, I guess they should be added to future PMA_* functions as</div><div>well?</div></div></div></blockquote><div>I am using javascript to wrap the code around at runtime. Any new function would be wrapped automatically if I do my job right </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><div id="quoted-message-content"><div><div><br></div><blockquote type="cite"><div><div>the javascript in phpmyadmin is just for aesthetics and caching but it</div><div>is not really very processor intensive anyway it is mostly about doing</div><div>things to the page and sending requests to the server and most of the</div><div>heavy lifting is done by jquery itself which I shall not change. The</div><div>benchmark is to show what happens in the extreme case which may be</div><div>problematic in node.js where the js code does heavy lifting and</div><div>performance hits are problematic. however for the simple javascript we</div><div>have, the negligible loss in performance cannot be perceived by the</div><div>end users. but the stack traces we get could significantly better</div><div>their experience in the long run.</div><div><br></div><div>I will be using an automated function to add the try and catch at</div><div>runtime so that there would be minimum modification to the codebase</div><div>and it can be easily removed if required.</div><div><br></div><blockquote type="cite"><div><div><br></div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><div><blockquote type="cite"><div>* We need to be able to easily turn off the error reporting feature</div></blockquote><div>You can do it simply by setting a config option I have already set it</div><div>up in the Header.class.php</div><blockquote type="cite"><div><div>* Some/most function names in the stack trace are going to be useless as</div><div>the production js code is minified.</div><div>* The line numbers in the file will not be of much help either, I guess,</div><div>unless we change the way that the files are minified (like forcing line</div><div>breaks every few hundred characters).</div></div></blockquote><div>since uglified js provides little to no information about the location</div><div>of the error. what should we do. I checked up on source maps however</div><div>the browser support is not enough. so what do you think should happen.</div><div>I think the only way to go is to add try and catch to all the</div><div>different functions if you need to find out where the error has</div><div>occured. however adding try and catch statements to the entire</div><div>codebase will decrease code readability considerably.</div></div></blockquote></blockquote></blockquote><div><br></div><div><br></div><div><br></div><div>------------------------------------------------------------------------------</div><div>This SF.net email is sponsored by Windows:</div><div><br></div><div>Build for Windows Store.</div><div><br></div><div>http://p.sf.net/sfu/windows-dev2dev</div><div>_______________________________________________</div><div>Phpmyadmin-devel mailing list</div><div>Phpmyadmin-devel@lists.sourceforge.net</div><div>https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel</div></div></blockquote><div><br></div><div>------------------------------------------------------------------------------</div><div>This SF.net email is sponsored by Windows:</div><div><br></div><div>Build for Windows Store.</div><div><br></div><div>http://p.sf.net/sfu/windows-dev2dev</div><div>_______________________________________________</div><div>Phpmyadmin-devel mailing list</div><div>Phpmyadmin-devel@lists.sourceforge.net</div><div>https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel</div></div></blockquote><div><br></div><div><br></div><div><br></div><div>--</div><div>Kind regards,</div><div><br></div><div>Dieter Adriaenssens</div><div><br></div><div>------------------------------------------------------------------------------</div><div>This SF.net email is sponsored by Windows:</div><div><br></div><div>Build for Windows Store.</div><div><br></div><div>http://p.sf.net/sfu/windows-dev2dev</div><div>_______________________________________________</div><div>Phpmyadmin-devel mailing list</div><div>Phpmyadmin-devel@lists.sourceforge.net</div><div>https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel</div></div></div>
</blockquote>
<div>
<br>
</div>