3 ms·
> Only to grind to a halt as soon as the workload changed just a little, haha. What really amazed me is the second time the mouse moved over the toolbar, towar
by logicchains 6y ago
> Only to grind to a halt as soon as the workload changed just a little, haha.
What really amazed me is the second time the mouse moved over the toolbar, towards the end of the video, it lagged less and was able to recover to the 200+fps much faster than the first time.
- fniephaus 6y agoCorrect, this indicates that recompilation occurred. The first time Graal compiled some of the UI machinery, which is all written in Smalltalk, no input events were triggered in the IDE. Consequently, the partial evaluator removed those code paths from compiled code. When we move the mouse over the window or start to click on UI elements, we cause recompilation, now with event handling compiled in. That's why these performance cliffs go away over time.
- tinco 6y agoWould it help to for example run a full test suite on your project, and use the compilation results of that as a sort of base? I remember a long time ago C# had a feature like this.
- fniephaus 6y agoIt would only if the test suite represents a realistic workload of your program. BTW: GraalVM EE has support for profile-guided optimizations: https://medium.com/graalvm/improving-performance-of-graalvm-native-images-with-profile-guided-optimizations-9c431a834edb https://medium.com/graalvm/improving-performance-of-graalvm-...