Published May 29, 2015
Today, HipBytereleased version 3.12with much faster compile times for iOS. This is great news!
In 3.11 and below, RubyMotion would spawn a new compiler instance for every file. With 3.12, they now boot up the compiler and fork the process for each file, sharing the compiler memory. This drastically reduces the boot-up time for each file.Watson came up with this methodology.
So, let's put it through its paces.
I tested a clean build for 3.11 vs 3.12, with and without Compressor on the latest version ofBeast Mode Fitness(new 1.1 version). I have a MacBook Pro 13" late 2013 dual-core 2.4ghz i5. Compressor is configured to concatenate only gem files (not
app), which is my recommendation. There are 323 total RubyMotion files, including 101 app files. We use theSandi Metz Rulesof small classes, one per file, so we always have lots of small files.
Note that with
rake build, RubyMotion actually builds it twice: once for the simulator architecture and once for device. So these numbers are actually inflated 2x from simulator-only builds (if you did
rake build:simulator). This shows a better average, since you'll be building for both architectures at some point in your development workflow.
Here are the results:
|RubyMotion 3.11||95 minutes||33 minutes|
|RubyMotion 3.12||5.6 minutes||6.6 minutes|
3.12 is much, much faster. It seems to be even faster without compressor, so at this point I don't think I'd recommend using it. That's about a 17X speed increase over non-compressor, and 5X faster than 3.11 compressor builds.
So far, I haven't noticed any regressions related to this. The app works fine in simulator.
Great work, HipByte!
(here is my
bundle exec rake build 2021.41s user 104.13s system 263% cpu 13:28.05 total
bundle exec rake build 5732.69s user 288.20s system 290% cpu 34:35.55 total
bundle exec rake build 400.95s user 53.42s system 176% cpu 4:17.46 total
bundle exec rake build 340.73s user 118.14s system 227% cpu 3:21.90 total