RubyMotion vs Xamarim vs RoboVM

[Harry Cheung]

Hey all,

I did a comparison between all the non-native mobile languages. Be warned, my results aren't favorable for RM.

https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9

Harry

[Ignacio Piantanida]

Hi Harry,

I don't want to sound rude, but those benchmarks without source are useless.

Maybe there is something that's not right about how you are handling objects, or maybe everything is "correct" and RubyMotion really has to improve it's performance. Unfortunately without code we won't know.

If you decide to release the code, please update this thread!!

Cheers

--
Piantanida, Ignacio Julián

@ijpiantanida

Harry

--
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS, OS X, and Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubymotion/4fedb8b4-2348-45f8-bee1-ef048e1eecca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Sinclair]

I'm also curious about the term "non-native". What exactly do you mean by that? Do you mean "native to the platform", or do you mean "compiled"? 

I have to be honest, I've done quite a bit of work with iOS using Objective-C and RubyMotion, particularly around geolocation stuff and my experiences with performance are nothing like you are reporting here. 

It'd be great to see the source code for your test suite so that we can make an objective and open comparison. 

Regards,

M@

[Harry Cheung]

Foot in mouth already. In prepping the source for release, I found a bug that affected memory performance. I've updated the post to reflect this.

Here's the source for the RubyMotion app: https://github.com/harrycheung/Mobile-App-Performance. I'll be adding the others slowly.

I'm totally ready to admit that my testing is incorrect, so please help me out. I want to see RubyMotion be more competitive.

Matthew, thanks for the "non-native" edit.

[Jamon Holmgren]

Hi Harry,

As you've dug into this more, have you revised your opinion of RubyMotion? I've done some benchmarking lately and have found some things that RM doesn't do quite as fast as the other languages, but the experience writing RubyMotion is so positive that the negligible (at the application level) differences in performance aren't a problem for me. But I'd like to hear what you think.

Jamon

[Colin T.A. Gray]

Since we’re on the topic, here’s a post about Swift performance, and he compares it to RubyMotion:

http://blog.sudeium.com/2014/12/10/swift-performance-too-slow-for-production/

Tyrone updated his results on this post using Swift 1.2:

http://blog.sudeium.com/2015/02/10/swift-1-dot-2-performance-pretty-much-fine/

Colin T.A. Gray

Community Manager

HipByte

--
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS, OS X, and Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubymotion/fa06cda2-2bd6-42e7-bc68-59a619343616%40googlegroups.com.

[Harry Cheung]

Jamon,

Since making the post, I've been notified by various people who specialize in each tool how to optimize my apps even further, and my post reflects those findings. No one with RM experience has helped me optimize my app to see if there's any vast improvements to be made. To answer your question, my opinion still remains that RM needs more work. If the compiled bytecode can't even be in the same ballpark as those other tools, I can't really expect it to perform less stressful computations in an efficient manner.

I'd be hard pressed to understand how Tyrone's number are a fair comparison. It's not clear whether or not he's using the same JSON library for his tests. However, my test case is a line-by-line translation, which will lead to more precise results.

Regarding Swift 1.2, Apple just release 6.3 Beta 2, which has a optimization flag. With this flag, my tests show that it is only 2-3% slower than Objective-C. Quite impressive indeed.

Harry

[Colin T.A. Gray]

This is certainly interesting from a "raw performance" standpoint, but I don't think that is the place where RubyMotion is wanting to contend *anyway*.  To me, RubyMotion is first and foremost all about using intuitive tools and language to build a native application.

These benchmarks have value, but they need to be placed in a larger context: what are the pain points in developing in Xamarin if you're used to a terminal-based workflow?

Also, I personally would never have this kind of "raw code" written in RubyMotion, I would vendor a small Obj-C library to do the heavy processing, and call that from my RubyMotion app.  Obviously, benchmarking this kind of thing wouldn't have any value in what you're trying to study.  I'm just pointing out that the "RubyMotion way" is not what you're studying here, this is more of an academic analysis.

Thanks for sharing it!

Colin T.A. Gray

Community Manager

HipByte