Open mykmelez opened 9 years ago
https://github.com/mozilla/j2me.js/pull/1303 is a first step.
I've added a few performance.now() calls to understand where we're spending time:
CldcMIDletSuiteLoader before init(): 3399
CldcMIDletSuiteLoader after init(): 3755
CldcMIDletSuiteLoader after createSuiteEnvironment(): 4519
CldcMIDletSuiteLoader after createMIDletSuite(): 4682
CldcMIDletSuiteLoader before startSuite(): 5058
MIDletTunnelImpl.callStartApp: 5791
BGUtils.startMIDlet: 7475
AmsUtil before isolate.start(): 7535
AppIsolateMIDletSuiteLoader after init(): 8872
CldcMIDletSuiteLoader before init(): 8909
CldcMIDletSuiteLoader after init(): 9856
CldcMIDletSuiteLoader after createSuiteEnvironment(): 9943
CldcMIDletSuiteLoader after createMIDletSuite(): 9968
CldcMIDletSuiteLoader before startSuite(): 9979
MIDletTunnelImpl.callStartApp: 10382
J2ME startup is fairly complex, with a variety of classes getting loaded and instantiated, and I wonder if it's all strictly necessary in our environment, which only runs a single midlet (or two, if there's a background midlet). Here's part of a stack trace that shows the complexity of the class hierarchy just to start a midlet:
And there are other classes that these classes load, like InvocationStore, whose purpose is apparently to queue invocations of other midlets (which doesn't happen in our environment, as far as I know; we do handle MIDlet.platformRequest, but that doesn't seem to use it).
We should investigate how much of this machinery we can remove while still enabling a midlet to load and run.