Google Groups

Re: The future of binary embedding


lkcl luke Feb 27, 2012 1:14 PM
Posted in group: mozilla.dev.embedding
btw, ben, about speed of using XPCOM through pyxpcom+hulahop...

when i said we don't care [because working is a higher priority than
speed, and it's a GUI anyway], i think it helps to give some context.

for the pyjs (compiled) version of any pyjamas application, the fact
that python is a dynamic language, being translated to another dynamic
language, gives a performance hit that's so high it's difficult for
people to believe it could be that bad, just to obtain python feature
interoperability.

[with the end result that they go off and implement their *own*
python-to-javascript compiler, in some cases.  this has actually
happened about four times, now!]

i spoke about this on b2g a couple of months back, when chris jones
(bless him) rather naively said that javascript was acceptable as the
de-facto "language of the web" implication being in absolutely all
circumstances because of projects such as dart, gwt and pyjamas.

if he'd ever run pyjs he'd've known that that simply isn't true,
because to even do something as simple as use the "add" operator, you
must check first if the two objects being added actually exist - which
must be done dynamically in case __getattr__ has to be used; then you
have to check the type of both objects (int? float? string?) and go
through a lookup table (!!) to find out if the two are compatible;
then you must coerce one type to the other; then _finally_ you can
actually add the two objects.

that very _very_ small and i mean small description should have you
going "oops..." and it should emphasise that maybe javascript as a
compiler target isn't such a good idea after all - not for dynamic
languages, anyway.

by contrast: for _static_ programming languages like java, c and c++,
it's great!

but for pyjamas, the performance hit is so high that when you run the
exact same application under pyjd it's a five-fold performance
improvement.

against that kind of background, and bearing in mind that that's still
using name-based lookups for absolutely each and every single access
to absolutely every single one of the functions, objects and
properties of DOM/HTML5, what we have right now looks very very good.

speed's *not* critical.  we're using xulrunner+xpcom+hulahop as a GUI
widget set.  a very powerful and flexible one.  pyjd doesn't have to
be lightning-quick. i've installed it on 400mhz ARM9 CPUs, and it had
perfectly acceptable performance.

l.