No description provided.
Replace Y.JSON.xxx with JSON.xxx for server affinities (faster)
Removed json-xx module dependencies from the requires list
This one is common affinity.
Let's just remove these logs, they should not be there, and if they do, they should never be using JSON.stringify, instead they should just pass the object as the first param, and mark it as "debug" to avoid computations when running in prod.
Same as above.
This is shipped to the client as well. WE need to keep using Y.JSON here.
- removed debug log statements that should not be using Y.JSON.xx
- restored 'json-xx' module in util.common.js (that is deployed to client)
I guess I'd ask to see the actual perf numbers here around 'faster'. IIRC, the Y.JSON call checks first to see if the platform it is running on has a native JSON call and just returns the value of that.
We just changed all 'JSON' calls to 'Y.JSON' to have consistency across the codebase not too long ago. If there is a huge perf win here, then yes for all 'server' affinities we can make an exception and use the raw 'JSON' call. Otherwise, my vote is to leave this as is.
Updated with feedback from @caridy
@imalberto looking good now +1
@add0n yes, according to Ric's tests, it is 5x faster :( a ticket for YUI has been raised I believe.
5X is certainly worth it.
In my mind this is a concrete example of the value of using an M prefixed namespace and isolating from YUI rather than tying ourselves so tightly to it we become dependent on their bug fix schedule. With an M.JSON wrapper we could fix this bug without affecting our API or changing anything but our internals. What will we do when YUI fixes their issue? Continue to have some code with YUI.JSON and some without? or change it back. Both are poor alternatives to taking ownership of the interface under a Mojito (M) prefix.
FYI tracked here: http://yuilibrary.com/projects/yui3/ticket/2532759
@mojit0 I strongly disagree on that. YUI will continue evolving, and fix should be done in YUI so everyone will get the benefit of it, not only mojito, but on top of that there is nothing that prevent us for adding a new module called 'json-stringify.server.js' in autoload as a replacement of the original one with the fix if it is absolutely needed.
@caridy I didn't mean to suggest that YUI won't evolve. My point was that without an insulating layer we can only evolve at the pace they evolve. I believe that we have evidence already that we may find that having our pace dictated by the YUI team may occasionally be burdensome and require us to do changes, such as this pull request, that are actually counter to our long-term API goals.
We should not merge this pull request. We should provide a workaround to the Y.JSON bug and remove it when we upgrade to a YUI version that contains the fix.
@jenny yes, this was merged to our search-perf branch to be able to evaluate how big is the impact as today. Before we merge back to develop we can clean this up.
Thanks for the clarification.