#pragma unroll

General
1

Floating this idea before filing a feature request…

Would it be possible or desirable to use a pragma like “#pragma unroll” to force the compiler to unroll a method into it’s calling function? Where speed is critical, this would give us a way to keep our code organized while still minimizing method calls.

For example, in my M_Crypto module, I had to manually unroll a bunch of methods to maximize the speed of Scrypt, AES, etc. Without doing that, there was a measurable speed difference, but now the functions are, well, ugly. Such a pragma would let me keep the code “neat” without sacrificing performance.

Thoughts?

2

As with most things in Xojo, it’s a matter of engineering time vs. benefit to userbase. I happen to think this is a fantastic idea, but it is not the sort of thing that most Xojo users would really understand or find useful. I fear that if you file a feature request for it we’ll all be dead before it is implemented.

Maybe I should stop looking through my list of feature requests - it just makes me jaded.

3

I, for one, very much like the idea

4

I would +1 this request, having an understanding of what it’s for and how it works.

But I think Kimball hit the nail right on the head. This is more of a power-user kind of feature, and not a “copy and paste code from the forum” level of skill - so I also think we wouldn’t see it implemented.

File the feature request anyway. It adds to their list of unhandled decades old requests. Maybe one day…

5

Thanks all for the input. I’d also like to hear from an engineer about feasibility before filing, but I’m glad I’m not the only one who’d like this.

6

you’re asking for “inlining” afaict (see http://www.cplusplus.com/articles/2LywvCM9/ )
so maybe #pragma inline

I’m not sure how much of that is done if you compile with moderate or aggressive settings

unrolling is usually literally applied to loops of known repetitions since you avoid certain overheads and linear code can be faster
(see https://en.wikipedia.org/wiki/Loop_unrolling) which isn’t quite what you’ve described

7

Yes, inline is exactly what I mean, thanks.

8

@Joe Ranieri would have to comment on how possible this is

9

Another thought is an attribute instead of a pragma.

10

Either way Joe still needs to comment on the feasibility

11

Inlining across compilation units, which more or less correspond to project items, isn’t possible at the moment because it would require some kind of link time optimization. Forcing inlining within the same compilation unit would be possible but not necessarily a win in most cases.

As for a pragma versus an attribute, I don’t think it’d make much difference. With an attribute you wouldn’t need to be able to see the body of the function to reason about inlining, but at the point you’re inlining you fundamentally already need to have the body of the function anyways.

12

Understood. Just curious, how hard would it be to implement within the same compilation unit?

13

Probably not exceedingly difficult. I’d prefer to get to the point where LLVM’s inlining heuristics will do most of this automatically, but Xojo functions right now have a bit of overhead due to stack overflow checking, reference counting and deterministic destruction, and exception handling.

14

I’ll file the request, thanks.

15

<https://xojo.com/issue/50352>

16

Rather than inlining, why not support the use of macros? That would probably be easier to implement, and should result in object code that is essentially the same.

17

It’s absolutely not easier to implement.

18

Yeah, after I posted that I realized that you’d have to preprocess the source code to expand the macros, which would likely be a major piece of work.

I was really thinking from my own point of view, if I wanted to inline the same code repeatedly, I could write my own macro preprocessor, and run it on my source code before building a project.