This question is similar to my other question(s) on the scope of enabling PGO, but this time scope in the sense of the existence of optimized binary code.
Will PGO start freshly over and over when the executable is run? Or will previously optimized code be re-used when the application is run again? (similar to the ngen.exe cache)
Are optimizations one-shot optimizations or can they dynamically adapt? For instance, if we have a time-tracking application and everyone is checking-in in the morning with an exceptional check-out, but in the evening it changes to everyone checking-out and no one checking-in. Will it reconsider the previous optimized version on-the-fly during the day?
Is there any way we can trigger it to re-optimize (similar to FREEPROCCACHE in SQL server to get rid of a bad query plan), e.g. restart the process would be the obvious answer if optimizations are not persisted.
Regular Time Interval setting in the advanced section of IIS application pool settings should be reconsidered after enabling PGO (we call it the memory-leak-garbage-collector) depending on the answers to the above questions (persisted or not).
Hope someone can shed some light into this cool black-box feature!
In normal usage, none of the data gathered by PGO persists outside the scope of the process that is using PGO.
Optimization decisions for a method are based on observations taken from the first N calls (roughly speaking, N = 30, though in practice it can be a lot more). If the method's behavior changes over a longer time span then the decisions made based on this initial look at method behavior may become sub-optimal. There currently is no provision for revising optimized methods once they're produced.