0

I just saw this bizarre statement on reddit

in theory, JIT will probably have better steady state performance for long running processes, because of things like dynamic profile guided optimization - the JIT compiler can optimize/change the native code (even multiple times) at runtime according to the actual execution pattern of your code

Really? Where can I find details from Microsoft to support this and also learn if there is a way to exploit it for my apps code?

EDIT: after @Hans Passant comments I am now concerned with this:

https://github.com/dotnet/runtime/blob/main/docs/design/features/tiered-compilation.md

At runtime the JIT is able to observe the exact dependencies that are loaded as well as CPU instruction support which allows it to generate superior code.

obviously there are performance costs of "observing" which is not something one wants to have in latency sensitive apps.

New question - can you disable this behaviour? In run-time or in deployment or in project settings? Can you disable this for certain projects but not another? What API exists that the end-users (devs) can manage this "feature"?

Boppity Bop
  • 9,613
  • 13
  • 72
  • 151
  • What's so bizarre about this? Every other high-performance JIT compiler does this, what reason do you have to believe Microsoft's doesn't? – Jörg W Mittag Mar 18 '23 at 13:25
  • 1
    https://github.com/dotnet/runtime/blob/main/docs/design/features/tiered-compilation.md – Hans Passant Mar 18 '23 at 14:09
  • 1
    https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1/ – Hans Passant Mar 18 '23 at 14:10
  • @HansPassant thank you, I edited the question - I need to know the perf costs of it and how to enable/disable/change this behaviour. would appreciate if you could give short - yes/no/dont bother answer :) [I am starting new WPF project in .NET 7 which by far beats all my previous experience in amount of real-time updates per sec, so "dont bother" isnt an option here] – Boppity Bop Mar 18 '23 at 15:49
  • This is of no concern when you start a project. You look at it when you're done and not happy about the Release build taking too time to get the UI responsive at startup. – Hans Passant Mar 18 '23 at 16:10
  • um.. no. I am talking about "Steady-State" part of the blog from your first comment.. Startup time is no concern indeed – Boppity Bop Mar 18 '23 at 16:16
  • I would argue that if "observing" cost is too much for your app - C# probably is not a right tool for you. – Guru Stron Mar 19 '23 at 14:11
  • Depending on the app type you can look into [Native AOT](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/) – Guru Stron Mar 19 '23 at 14:12
  • .net core wpf does not implement aot afaik – Boppity Bop Mar 19 '23 at 14:20
  • _"I am starting new WPF project"_ - AFAIK that WPF by default has 60 FPS, I doubt that the "observability" cost will affect that in any meaningful way. – Guru Stron Mar 19 '23 at 14:20
  • Also maybe something can be done with [crossgen](https://github.com/Potapy4/dotnet-coreclr/blob/master/Documentation/building/crossgen.md) – Guru Stron Mar 19 '23 at 14:21
  • Where did you get that number? In old.net framework there was a wpf profiler that would show fps. I can't remember if I saw 60 number but fps would vary during lifetime of an app a lot. You sure about the hard limit? Would that limit apply on each window (eg if they run in separate UI threads) or on the whole app – Boppity Bop Mar 19 '23 at 14:24
  • Answer here says it can be higher than 60: https://stackoverflow.com/questions/39098210/correct-way-of-measuring-ui-performance-in-wpf-net – Boppity Bop Mar 19 '23 at 14:31
  • @BoppityBop I have not found the source but seen it multiple times. Also note that if we are talking about UI - higly doubtful that human eye can distinguish delays which can be caused by the "observability" tools. I would not expect them to be higher than 10th of CPU cycles. – Guru Stron Mar 20 '23 at 06:23
  • this is highly debatable. i am sure (from my previous exp) you can detect *rate* of changes if you animate changes and it grows from 8k cells to 10k in 200ms (changes can happen on 6 monitors and multiple people can be looking).. if it is 10 CPU cycles then perhaps you are right. but still it would be better to have access to such information. because things happen. people screw up and may be there are cases when it is 10 mil CPU cycles and nobody would know for years.. until some pesky git like me push their nose into it.. – Boppity Bop Mar 20 '23 at 08:22
  • P.S. although google gives 200ms as an eye saccade time, from what I know a young trained individual can react on visual changes faster (150ms?) which (considering time to process the eye input and send signal to a muscle group and produce *reaction* is probably 100ms, leaving to eye 50ms not 200). – Boppity Bop Mar 20 '23 at 08:48

0 Answers0