Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Elia Schito
@elia
oh, yeah, so the problem includes when the method is assigned to the prototype…
Julian Scheid
@jscheid
so what I'm proposing is to switch to always use [] here
the downside being a small increase in file size when it's not post-processed
however, pretty much everything can optimize that away (uglifyJS can as well, I'm 99.99% sure)
personally I think it's an acceptable trade-off if it buys the ability to run output through GCC
elia @elia looking at defn code again
Elia Schito
@elia
$defineProperty(proto, jsid, body);
Julian Scheid
@jscheid
ah ok... well, same difference
Elia Schito
@elia
that's how the property is set, and for good reason, so it's a no go I think
Julian Scheid
@jscheid
what is a no go?
Elia Schito
@elia
switching it to proto[jsid] = body
Julian Scheid
@jscheid
ah no that's not necessary
it's effectively the same
Elia Schito
@elia
GCC can see trhu that?
Julian Scheid
@jscheid
good question... I'm not sure now, but it doesn't really have to. the way it works is this:
let's say proto is foo and jsid is bar
when it sees foo['bar'] it leaves bar alone, and the expression will work regardless of how foo.bar was set (with foo[bar] or with defineProperty)
but when it sees foo.bar, it will mangle bar into something short, maybe into foo.y
and then it won't match anymore
does that make sense?
so at least in a first step, we don't have to change anything in how Opal.defn works
only in how the rest of the code accesses properties
Elia Schito
@elia
oh I see, it's the reverse of what I thought, I was believing that you wanted to allow GCC to optimize method names, but really you want to prevent them from being touched, right?
Julian Scheid
@jscheid
long term I think it would be great if we could let GCC optimize that stuff
the methods names would be nice if they were a little shorter, but the killer features of course is dead code elimination
I just think that's quite a bit of work, and so in the short term I'm suggesting to do it the other way around, as a quick fix that lets people use GCC with ADVANCED_OPTIMIZATIONS
Elia Schito
@elia
question: is there a way to tell GCC not to touch some names?
Julian Scheid
@jscheid
yes, with an externs file
that's how I have my test case working
it has lots of lines that look like this:
Opal.modules["corelib/module"].$class_variable_get = function() {};
it works -- it's just a PITA
and it only works for my case, I have lines like that for the code I'm compiling as well
obviously
Elia Schito
@elia
hmm, asking because we have the list of method calls for each file, and maybe an externs file can be generated
elia @elia is looking up the docs
Julian Scheid
@jscheid
hmm interesting thought... but why are you opposed to changing . to [] instead? the way I see it: people who care about file size will run the result through a compressor anyway, and that will turn it back into .s (or do something even smarter when it's GCC)
or is there another reason besides file size why you're not keen to make that change?
and it'll be a simpler system with fewer moving parts that way
Elia Schito
@elia
Not opposed on principle, except for readability of the generated code (which is of course not a strong argument), I just need to be sure there's no hidden reason not to that I'm forgetting
right now I'm experimenting with uglily to see how it would handle it
Julian Scheid
@jscheid
okie dokie
I gotta run but I'll pop back in tomorrow after doing some experiments with mid_to_jsid
but just to whet your appetite...
the lib I'm compiling with opal ends up as a 2 MB JS file
uglify gets it down to 1.6 MB
closure compiler down to 1 MB ... and that's without any DCE
maybe I'll have some performance benchmarks tomorrow as well
:wave: