[ANN] Faster objj_msgSend function. Testing help needed

61 views
Skip to first unread message

Martin Carlberg

unread,
Apr 8, 2014, 3:59:34 PM4/8/14
to objec...@googlegroups.com
Hello all!

As we are closing in on the 'go live' date on our project I have spent some time on speed improvements. Always when I run performance tools on the application the objj_msgSend function comes out on top as the place where the most time is spent.

After a few days I started to think maybe I should look at this function and see what can be done. Nothing has changed with it for at least 4 years. I have now created a pull request with some speed improvements. http://github.com/cappuccino/cappuccino/pull/2103

I need help from others to test this and get feedback on what kind of speedup or slowdown we get from this. I have seen a speedup in some cases of up to 5-10%. But does this have any other undesired effects?

Some test cases don't work but they are related to how the compiler generates code for the objj_msgSend function. Also the last flatten test case fails with out of memory for some unknown reason.
The debug objj_msgSend_set_decorators functions are not supported right now. Maybe they don't need to if we only use this speed improvement for release builds.

Ok, how is this speed improvement done?

The old objj_msgSend function always checks if the class needs to be initialized. It also checks how many arguments are passed into the method. The last check is to improve the call to the method implementation with the correct number of arguments.

These two checks are eliminated by this pull request.

Please try it out and give me feedback. I need to know if this is something I should continue to work on. http://github.com/mrcarlberg/cappuccino/tree/fast_msg_send


Best regards,

- Martin

Alexander Ljungberg

unread,
Apr 8, 2014, 4:48:08 PM4/8/14
to objec...@googlegroups.com, Martin Carlberg
Hi Martin,

Great work! The idea of using multiple versions of objj_msgSend depending on the number of arguments has come up before on this list but no-one gave it a go before that I know of. Very exciting to see you work on it.

The special initializer version of msg send is a new idea, I think. I like it.

These changes do make message send decorators a whole lot trickier - now to decorate message send or to remove a decorator one would have to visit every single class. Decoration is useful even in release builds when tracing code or collecting info on all methods used.

There should be a small memory hit I guess as we get 5 more pointer variables on each class object.

Do you have any more detailed numbers on memory usage and how much of the improvement is from arguments handling versus from removing initialize checks?

Alexander
--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectivej+...@googlegroups.com.
To post to this group, send email to objec...@googlegroups.com.
Visit this group at http://groups.google.com/group/objectivej.
For more options, visit https://groups.google.com/d/optout.

Martin Carlberg

unread,
Apr 9, 2014, 12:47:11 AM4/9/14
to objec...@googlegroups.com
Hi!

Good to know that message send decorators are used in release builds too. I'll see if I can't get that to work again.

I can't see any increase in the memory usage in our project from this but as you say it should be a small hit.

I also forgot to share my tests on http://jsperf.com/objective-j-send-message/4

What it tells us is that both improvements give us significant speedups, but the argument handling looks like the biggest.

The bad thing is that these tests does not give us what the real speedup is in a real world application. As I said we get up to 5-10% and it should be very interesting to find out what others get? So please try it out and post your findings.

- Martin
Reply all
Reply to author
Forward
0 new messages