For got to provide a link to the performance comparison site
http://jsperf.com/function-call-vs-inline
Sarvi
On Tuesday, October 22, 2013 10:21:21 PM UTC-7, Sarvi Shanmugham wrote:
>
>
>
> On Tuesday, October 22, 2013 9:42:19 PM UTC-7, Kees Bos wrote:
>>
>> On Tue, 2013-10-22 at 20:29 -0700, Sarvi Shanmugham wrote:
>> > I tried to hack a bit to simplify the generated code to see how it can
>> > be done and this is what I got.
>> > I left the $ alone for the reasons Lex mentioned. Turned the
>> > dictionary accesses into object notation and
>>
>> That looks cleaner, but inhibits the use of closure compiler, since that
>> will mangle object attributes (at high optimization).
>>
> would you refering me to something that explains this? I am relative noob
> with this stuff.
>
>
>> > reduced some of the repetitive code into functions that do the same
>> > code.
>> > From what I tested of inlining, JITs should take care of inlining
>> > these with no performance impact.
>> > and it was relatively simple, repetitive but sizable changes to the
>> > translate_proto.py code to do this.
>>
>> Did you do performance comparisons, on different engines, probably
>> (arguably) including IE8 for those that still use XP and refuse to
>> install something different? It used to matter a lot whether you use
>> function calls or inlined (<test>?<cond1>:<cond2>).
>>
> expalined below.
>
>>
>>
>> > /* start module: test1 */
>> > $pyjs.loaded_modules.test1 = function (__mod_name__) {
>> > if ($pymdecorate(this,'test1',__mod_name__)) return $m
>> >
>> >
>> >
>> > $m.hello = function(i) {
>> > return multiply(multiply(multiply(i,i),2),25);
>> > };
>> > $pyfdecorate($m.hello,'hello',0,[null,null,['i']]);
>> >
>> >
>> > return this;
>> > }; /* end test1 */
>> >
>> >
>> >
>> >
>> > /* end module: test1 */
>> > The result would from what I can see would be much simpler, readable
>> > and a lot less code
>> > Would something like this be accepted if I work on finishing this?
>>
>> Depends... on the speed of the result. Since this is only meant to
>> generate simpler/cleaner/smaller code (which are for _me_ minor issues
>> compared to speed), this might not be way to go in _my_ opinion.
>>
>> My guess (when I see this generated code) is that it will run about 5
>> times slower than what's currently generated (with --strict option). But
>> please, prove me wrong :-)
>>
> I found this interesting site that measures exactly this :-)
> Compare the Orange and Blue graphs for each browser for what we need here.
> Every browser shows quite comparable performance, infact almost equal
> between inlining and using a function.
> Except, now I hate IE even more, IE. Even the latest one sucks at this.
> :-))
>
> Sarvi
>
>
>>
>> - Kees
>>
>>
>>
--
---
You received this message because you are subscribed to the Google Groups
"Pyjs.org Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
