On Monday, June 24, 2013 at 4:19 PM, Dieter Adriaenssens wrote:
2013/6/22 Mohamed Ashraf <mohamed.ashraf.213@gmail.com>:
On Sat, Jun 22, 2013 at 10:27 AM, Rouslan Placella <rouslan@placella.com> wrote:
On 06/22/2013 01:21 AM, Mohamed Ashraf wrote:
On Saturday, June 22, 2013 at 12:49 AM, Rouslan Placella wrote:
On 06/16/2013 12:59 PM, Mohamed Ashraf wrote:
On Wed, Jun 12, 2013 at 9:58 AM, Rouslan Placella
<rouslan@placella.com> wrote:

Some of my thoughts are:

* Try/catch has a performance penalty
it is not too big as can be seen here
http://jsperf.com/try-catch-performance-overhead

Really? On some browsers it's about 20 times slower on the very
benchmark that you are linking to!
Really!! That is strange I tested it multiple times and everytime it
showed they are all equal in time. Which test case was 20 times slower?

Opera 11 would be one of them. IE 10 is also quite bad, but by a lower
magnitude...

the reduction in performance is usually in wrapping the inside of a
function with try and catch. I was thinking of doing the other way and
wrapping the functions from outside like this

var temp = PMA_foo
PMA_foo = function() {
try{
temp.apply(window, arguments);
} catch(e) {
my_method(e);
}
}

I am thinking of doing this to all global functions starting with PMA_
and according to the benchmark this should have an equivalent
performance to the no try catch performance. also if we don't do
anything of the sort then we would never get a stacktrace.

Just wondering, if you add try-catch phrases to the current PMA_*
functions, I guess they should be added to future PMA_* functions as
well?
I am using javascript to wrap the code around at runtime. Any new function would be wrapped automatically if I do my job right 

the javascript in phpmyadmin is just for aesthetics and caching but it
is not really very processor intensive anyway it is mostly about doing
things to the page and sending requests to the server and most of the
heavy lifting is done by jquery itself which I shall not change. The
benchmark is to show what happens in the extreme case which may be
problematic in node.js where the js code does heavy lifting and
performance hits are problematic. however for the simple javascript we
have, the negligible loss in performance cannot be perceived by the
end users. but the stack traces we get could significantly better
their experience in the long run.

I will be using an automated function to add the try and catch at
runtime so that there would be minimum modification to the codebase
and it can be easily removed if required.


* We need to be able to easily turn off the error reporting feature
You can do it simply by setting a config option I have already set it
up in the Header.class.php
* Some/most function names in the stack trace are going to be useless as
the production js code is minified.
* The line numbers in the file will not be of much help either, I guess,
unless we change the way that the files are minified (like forcing line
breaks every few hundred characters).
since uglified js provides little to no information about the location
of the error. what should we do. I checked up on source maps however
the browser support is not enough. so what do you think should happen.
I think the only way to go is to add try and catch to all the
different functions if you need to find out where the error has
occured. however adding try and catch statements to the entire
codebase will decrease code readability considerably.



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel



--
Kind regards,

Dieter Adriaenssens

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel