On 6/10/2011 10:24 AM, C. Scott Ananian wrote:
On Jun 9, 2011, at 5:58 AM, Julian Leviston<[email protected]> wrote:
On 09/06/2011, at 7:04 PM, BGB wrote:
actually, possibly a relevant question here, would be why Java applets largely fell on
their face, but Flash largely took off (in all its uses from YouTube to "Punch The
Monkey"...).
My own opinion of this is the same reason that the iPad feels faster than a
modern desktop operating system: it was quicker to get to the user interaction
point.
Julian.
The slow startup time is indeed why Sun's own team felt that Java
failed to get traction. Unfortunately some basic architecture choices
in the standard library made it extremely difficult to fix the
problem. (Broadly, how class initialization is handled and used.) The
latest Java plugins contain some impressive engineering to mitigate
the problem, but Java is still sluggish to start in my experience.
Library design matters!
--scott
yep... Java does a lot of things in the library which could generally be
considered a bad thing for performance.
one thing that took my attention before was noting just how many cases
there are of operations taking the form:
"new Something(...).someMethod(...);".
in places which could potentially impact performance if one is not
careful (at least presuming the VM doesn't infer that the object is
one-off and micro-optimize it some).
just had an idle thought of a JVM starting up as a prebuilt "image"
(say, methods are pre-JIT'ed and pre-linked, static fields are
pre-initialized, ...).
unless of course, they already started doing this (sadly, I am not much
an expert on the JVM).
AFAIK, the main strategy generally used is to demand-load classes
one-at-a-time from the JAR files, potentially validate them, JIT their
methods, and call the "<sinit>" or similar static method. this process
then may partly play out recursively, each class causing demand-loading
more classes, ... until all relevant classes are loaded.
or, maybe it is that, within the class library, most classes are tangled
up with many other classes, essentially turning the class library into
some large bulk-loaded glob?...
well, not that my VM can say that much... sadly, in the present
architecture, the toplevel is executed, which may in-turn load more code
(the toplevel is itself a giant static initializer, and any
functions/classes/... are built when their code is executed).
a sad result of this is that using executable statements/expressions in
the toplevel, it is possible to fetch 'null' from slots prior to them
being initialized, creating ordering issues in some cases.
say:
var foo=[bar, "bar"];
function bar() { ... }
foo[0] will currently hold null...
this is not an issue for normal calls though, since the call will
generally happen following any needed functions having been assigned to
their slots.
addressing the issue at present would likely require ugly hacks.
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
