From a user perspective, I find the statement that "Lean Clojure" works based off these charts a bit daring. Why?
a) Without having access to the numbers, (Skummet) startup is ~5 times as slow as the Java version. That is a noticeable difference. Plus, even Java apps sometimes tend to take a second or more to start up if they're reasonably complex.
b) The "Lean Clojure works" statement is derived from comparing _only_ the startup times. The fact that the task time is around two times Java's for Skummet is a big thing. Ignoring startup time, and without further data/tests, one could argue that Clojure Android apps run twice as slow as Java ones... that's a big no-go given the high amount of sparkly UI features of most modern apps. Or at least a no-go for having a Clojure-only stack?
(Skummet's probably in its early stages and I'd expect improvements but ... from those graph I'd argue 'Lean Clojure' does not work (yet?))
To clarify my statement: the idea of lean Clojure for making Clojure viable for Android development basically works. More static compilation of vars dramatically reduced startup times; I think further "lean Clojure" changes like dependency shaking would bring equally dramatic improvements. I'm handwaving a bit here at the challenges involved in making further changes, but the direction seems quite promising, at least for reducing startup times.
General performance is more difficult to speak for. If it is within a factor of two of Java that seems pretty similar to Clojure vs Java on the desktop and is a tradeoff many are willing to make. It's also true that Clojure relies heavily on Java libraries and Android app performance is highly dependent on underlying library and native performance. So basically for run time performance I don't think the performance of Clojure itself is the most significant factor.
a) Without having access to the numbers, (Skummet) startup is ~5 times as slow as the Java version. That is a noticeable difference. Plus, even Java apps sometimes tend to take a second or more to start up if they're reasonably complex.
b) The "Lean Clojure works" statement is derived from comparing _only_ the startup times. The fact that the task time is around two times Java's for Skummet is a big thing. Ignoring startup time, and without further data/tests, one could argue that Clojure Android apps run twice as slow as Java ones... that's a big no-go given the high amount of sparkly UI features of most modern apps. Or at least a no-go for having a Clojure-only stack?
(Skummet's probably in its early stages and I'd expect improvements but ... from those graph I'd argue 'Lean Clojure' does not work (yet?))