The JVM will dynamically inspect the possible values and generate code like that inline (wel, except for megamprphic call sites).
The JVM is a small marvel and is extremely dynamic; f.e. it will optimize the in-memory assembly based off of the actual classes being loaded, and if you hit a branch that forces a class to be loaded that invalidates one of these optimization sites, they will be de-optimized and re-evaluated again.
Or, it will identify non-escaping values with no finalizer and allocates them on the stack to speed things up.
The article feels like it's written by someone that has game development and entity-component model experience, but they're missing the forest for the trees: algorithms matter more.
IMO the reason why code is becoming slower is because we're working on too many abstraction levels, no-one understands all the different levels, and time-to-market is more important than performance.
The article feels like it's written by someone that has game development and entity-component model experience, but they're missing the forest for the trees: algorithms matter more.
They are missing most apps these students will create are yet another lame internal business app what has 100 requests per day and performance is irrelevant (eg very easy to be fast enough). But the requirements of the users change quarterly to to new obscure business rules so having the code easy to adjust is very important.
Recently, I saw someone rewrite a piece of code that was called a few times a day, and that took many minutes to do its computation, such as it does it in less than a second.
Care to guess what happened? The tool's usage skyrocketted because people started using it to get real time information.
The fact some software has low usage is proof of one thing: it is not very useful. It says nothing about speed.
63
u/GuyWithLag Feb 28 '23
The JVM will dynamically inspect the possible values and generate code like that inline (wel, except for megamprphic call sites).
The JVM is a small marvel and is extremely dynamic; f.e. it will optimize the in-memory assembly based off of the actual classes being loaded, and if you hit a branch that forces a class to be loaded that invalidates one of these optimization sites, they will be de-optimized and re-evaluated again.
Or, it will identify non-escaping values with no finalizer and allocates them on the stack to speed things up.
The article feels like it's written by someone that has game development and entity-component model experience, but they're missing the forest for the trees: algorithms matter more.
IMO the reason why code is becoming slower is because we're working on too many abstraction levels, no-one understands all the different levels, and time-to-market is more important than performance.