`-compile(inline)` pros and cons

Hello friends!

The Erlang compiler has an opt-in inline mode, where it will inline small functions. A friend and I were talking about it and gave it a try, and we came to these advantages and disadvantages:

:white_check_mark: Performance the same or improved in the code we tested
:white_check_mark: No real change in code size with default configuration
:cross_mark: function_clause exceptions are converted to similar case_clause exceptions
:cross_mark: Inlined functions will no longer show up in the stack traces

Are there any other properties that have been missed?

To me this seemed like quite a nice trade off. Is there a reason not to use it often? Providing we are happy with the worse strack traces and change in exceptions.

Thanks,
Louis

3 Likes

Naively, code size may become an issue if the function is both large and heavily used. So I would be very careful claiming that there is no size increase. But I also know nothing about the inline mode. Never even opened its documentation.

The obvious question about exceptions is whether you have any code that cares about function clause vs case clause, other than to log it and give you some clue where the fault symptom appeared. Do you have anything that tries to catch one but not the other, or handles them differently?

Tail call optimisation already means that the stack does not record all the functions, so if you can live with that maybe you can live with the other.

A general rule is to profile on a realistic workload before inlining.
It might pay off to inline one biggish function than ten little ones. It all depends on what they do and how they are used.

1 Like

As I said it doesn’t increase code size with the default configuration as it only inlines sufficiently small functions.

Aye, this is where we ended up, with these being the only disadvantages. Can you think of anything else?

You also can’t trace inlined function - this can limit debugging opportunities

1 Like

I would actually say the default limits are perhaps too conservative. I suppose they were probably set when machines generally had smaller caches, etc. I think you can actually get away with setting them substantially higher whilst seeing a reasonable size-speed trade-off. Of course, more inlining will make the issues regarding changes in tracing, exceptions, etc. more obvious.