Running Ceylon programs too slow?

[FroMage]

See thread at https://www.reddit.com/r/ceylon/comments/44c3i5/ceylon_is_insanely_slow_need_help/ claiming running takes 4s just for the initialisation. We have to check this.

[FroMage]

So I can see a 1s in metamodel initialisation, on the 1.3s startup time. This appears to be related to just scanning jars for packages. Quite crazy cost. I'll try to remove this.

[FroMage]

Ah, red herring. That's not it. Removing the metamodel initialisation entirely gained 100ms.

[FroMage]

After more careful analysis, we spend a lot of time iterating zip entries in BytecodeUtils (we could improve by looking for the right module file) and a lot of CPU checking sha1 for artifacts

[FroMage]

That SHA1 checking alone takes about 40ms out of 400ms, so 10%. Perhaps we should only do this for the cache repo?

[jvasileff]

Is SHA1 checking at runtime necessary at all?

• All copies and transfers should of course be checked, to protect against truncation, etc. But once on your local filesystem, corruption is much less likely
• Locally, there is no security benefit. A hacker can easily replace the sha1 file if they can replace the car
• I'd guess that filesystem corruption is more likely to cause a significant runtime failure than an obscure, hard to understand bug
• Does the JVM perform a checksum on its files, or just byte code validation?

[quintesse]

I'd say get rid of it locally (I thought it was done on downloads only anyway).
40ms is not something we're really going to notice much, still all together things add up I guess.

[FroMage]

So, after getting rid of sha1 checks for local files and making the metamodel init more lazy:

mode	1.2.1	1.2.2
flat cp	1.1s	0.56s
jboss modules	1.25s	0.75s
main API	x	0.4s
main	x	0.1s

Let's see if I can shave some more.

[FroMage]

For comparison, running with the Main API takes 0.4s, and running our program with no metamodel initialisation (without the Main API: straight Java call to our module's main) takes 0.1s. So there's still room for improvement :(

[FroMage]

I can't seem to be able to profile this more. I get very few sample counts for methods. I suspect the XML parser for module.xml partly, and the custom class loaders in the two first cases. For the "main API" it's quite puzzling but could be due to walking the jars.

IMO we should be able to bring the jboss modules case down to closer to the flat classpath mode. Both of those use custom classloaders (plus Launcher) so that has a cost we probably can't reduce further. They also use the CMR.

We should be able to drag the "main" API case down to the "main" case too, if we're better at scanning the jar files for setup.

[FroMage]

I've created #6027 about the CMR checksum checks, and #6028 about JDK imports in JBoss Modules.

[FroMage]

I've done all I could for this one for 1.2.2. I'll move for 1.2.3 for the rest. I've already doubled perf, so it's not too bad.

[jvasileff]

It's unsurprising to see that the original post has been deleted.

One piece of info that would be lost is that the timings were copied-and-pasted for maximum effect. The ~4s result was for the "user" output of time which represents total cpu, not "real" which is usually much less for ceylon run on multi-core machines. I'm sure they're both important to look at.

BTW–this look great! This will be a much appreciated enhancement.