Quantcast

Understanding the impact of trampolines

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Understanding the impact of trampolines

slodge
I've hit a few problems in apps with running out of trampolines - especially because I used DI with lots of interfaces.

To get around this I've tried command line changes like:

-aot "nrgctx-trampolines=4096" -aot "nimt-trampolines=4096" -aot "ntrampolines=4096"

However, I'm not really sure what I'm doing here.... I know the defaults are 1024. What impact does changing these values have on performance, on image size or anything else? Is there any guidance available on these numbers? Does it matter that I'm increasing all 3 values together? Or should I just focus on the one(s) that seem to be giving me problems?

Thanks

Stuart
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Understanding the impact of trampolines

Rolf Bjarne Kvinge
Hi Stuart,

On device we generate all the necessary code at build time in a process known as Ahead of Time compilation (similar to Microsoft's ngen), because we're not allowed to jit code on devices. Unfortunately there are a few things that cannot be determined statically - for instance generic interfaces might need different vtables depending on which type the interface is instantiated with. (For this case it is technically possible to determine the maximum number of vtables, but the number would be potentially enormous - multiply the number of generic interfaces times the number of types in your app...). We cannot allocate memory for these vtables dynamically at runtime, so we've picked a reasonable default and allow the user to increase this value if they run into issues. This is the basic theory for the trampolines (the exact problem is a bit different, depending on the type of trampolines, but that's not really important).

So you can add as many trampolines as you want, but memory usage will increase. That's also all there is to it: the app will not get slower (unless if the increased memory usage causes it to run slower, due to out-of-memory warnings, etc). It also means that you only have to increase the number of trampolines of the type you're actually having problems with, if you increase the others you'll increase the size of your executable needlessly.

I hope this helps,
Rolf

On Thu, Mar 22, 2012 at 11:17 AM, slodge <[hidden email]> wrote:
I've hit a few problems in apps with running out of trampolines - especially
because I used DI with lots of interfaces.

To get around this I've tried command line changes like:

-aot "nrgctx-trampolines=4096" -aot "nimt-trampolines=4096" -aot
"ntrampolines=4096"

However, I'm not really sure what I'm doing here.... I know the defaults are
1024. What impact does changing these values have on performance, on image
size or anything else? Is there any guidance available on these numbers?
Does it matter that I'm increasing all 3 values together? Or should I just
focus on the one(s) that seem to be giving me problems?

Thanks

Stuart

--
View this message in context: http://monotouch.2284126.n4.nabble.com/Understanding-the-impact-of-trampolines-tp4495086p4495086.html
Sent from the MonoTouch mailing list archive at Nabble.com.
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch


_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Understanding the impact of trampolines

slodge
Thanks Rolf

All seems to make some sense - and at least I understand now that this is type not instance based. I've not found any easy way to work out the numbers, so for now I'm increasing all 3 - but only to 2048, not to 4096. If and when the users start seeing out of memory errors, then I'll know that this is one of the places where I can try to optimise.

Thanks again

Stuart

On 22 March 2012 23:43, Rolf Bjarne Kvinge [via MonoTouch] <[hidden email]> wrote:
Hi Stuart,

On device we generate all the necessary code at build time in a process known as Ahead of Time compilation (similar to Microsoft's ngen), because we're not allowed to jit code on devices. Unfortunately there are a few things that cannot be determined statically - for instance generic interfaces might need different vtables depending on which type the interface is instantiated with. (For this case it is technically possible to determine the maximum number of vtables, but the number would be potentially enormous - multiply the number of generic interfaces times the number of types in your app...). We cannot allocate memory for these vtables dynamically at runtime, so we've picked a reasonable default and allow the user to increase this value if they run into issues. This is the basic theory for the trampolines (the exact problem is a bit different, depending on the type of trampolines, but that's not really important).

So you can add as many trampolines as you want, but memory usage will increase. That's also all there is to it: the app will not get slower (unless if the increased memory usage causes it to run slower, due to out-of-memory warnings, etc). It also means that you only have to increase the number of trampolines of the type you're actually having problems with, if you increase the others you'll increase the size of your executable needlessly.

I hope this helps,
Rolf

On Thu, Mar 22, 2012 at 11:17 AM, slodge <[hidden email]> wrote:
I've hit a few problems in apps with running out of trampolines - especially
because I used DI with lots of interfaces.

To get around this I've tried command line changes like:

-aot "nrgctx-trampolines=4096" -aot "nimt-trampolines=4096" -aot
"ntrampolines=4096"

However, I'm not really sure what I'm doing here.... I know the defaults are
1024. What impact does changing these values have on performance, on image
size or anything else? Is there any guidance available on these numbers?
Does it matter that I'm increasing all 3 values together? Or should I just
focus on the one(s) that seem to be giving me problems?

Thanks

Stuart

--
View this message in context: http://monotouch.2284126.n4.nabble.com/Understanding-the-impact-of-trampolines-tp4495086p4495086.html
Sent from the MonoTouch mailing list archive at Nabble.com.
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch


_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch



If you reply to this email, your message will be added to the discussion below:
http://monotouch.2284126.n4.nabble.com/Understanding-the-impact-of-trampolines-tp4495086p4497367.html
To unsubscribe from Understanding the impact of trampolines, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Understanding the impact of trampolines

steott@gmail.com
In reply to this post by Rolf Bjarne Kvinge
Thanks for the explanation Rolf, I didn't find this in other places... maybe you could add this to the troubleshooting section :)

Can you give any idea (even as order of magnitude) of the increse of memory usage? For example if I increment trampolines of type 2 from 128 (default) to 512, or to 2048 as slodge did, how much the memory usage will increse? some megabytes? tens of megabytes? thousands of kilobytes?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Understanding the impact of trampolines

Rolf Bjarne Kvinge
Hi,

On Mon, Mar 26, 2012 at 9:09 AM, [hidden email] <[hidden email]> wrote:
Thanks for the explanation Rolf, I didn't find this in other places... maybe
you could add this to the troubleshooting section :)

Can you give any idea (even as order of magnitude) of the increse of memory
usage? For example if I increment trampolines of type 2 from 128 (default)
to 512, or to 2048 as slodge did, how much the memory usage will increse?
some megabytes? tens of megabytes? thousands of kilobytes?

You'll measure the difference in kilobytes (exactly how many I don't know). The easiest way to see the impact though is to do a before-and-after size measurement of your app.

Rol

_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Loading...