7 ms·

I’m also a long time java spring developer. I started writing a game recently and was really surprised about how bad the performance can be when you run it in a

by pylua 2y ago

I’m also a long time java spring developer. I started writing a game recently and was really surprised about how bad the performance can be when you run it in a tight game loop. The startup time is also a real problem, as you really want to be able to scale up pods quickly. That said, it’s good enough right now. You can make it work at scale, and it’s worth the cost trade off of trying to do it more efficiently in a different language. I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze?

cmrdporcupine 2y ago
Most "microservice" backend type stuff is I/O bound, not CPU bound. You're likely not going to win much. Maybe get away with lower memory instances though.
- rahen 2y ago
  Cold latency is an issue with microservices. If you need to use Java, you'll likely end up using frameworks like Spring or Quarkus, which somewhat diminish the advantages of using the JVM and Java as a language. At that point, you might as well start with Go from the beginning.
  - gf000 2y ago
    Is it really an actual issue? How often do you restart instances or scale up horizontally? A cheap 10 years old desktop PC can easily handle all the traffic a medium-sized website generates at all times.
    - pylua 2y ago
      What do you define as medium size?
      - gf000 2y ago
        Stackoverflow famously ran on a single, although quite beefy server PC for a long time (not any longer, but not for performance reasons AFAIK). I think it's a good data point to have to scale your workload to stackoverflow's, and reconsider the hardware costs. (Obviously horizontal scaling has its place, but if it's that variably scalable, maybe there are better solutions, e.g. a single bigger instance -- often times even for cheaper)
- tugberkk 2y ago
  why the downvote on this? is it wrong?
throwaway2037 2y ago
> I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze? So, replace cheap Java developers for expensive Rust devs to squeeze out some savings? It makes no sense to me.
- tonyhart7 2y ago
  well if the argument is cheaper, I can argue that JS/python dev would be more cheaper since there are more pool of talent
  - throwaway2037 2y ago
    Double agree. If Java was the right choice 10-15 years ago for cheap enterprise apps, then certainly NodeJS is the way to go today. There are heaps of cheap developers and the ecosystem is ginormous.
    - pylua 2y ago
      Is it really to the point of challenging java ? Seems like Java is still the way to go here.
rootlocus 2y ago
Have you tried AoT compilation with graalvm?
- pylua 2y ago
  No, the product has a lot of aop and I figure it would be difficult to make that work.
znpy 2y ago
> The startup time is also a real problem, as you really want to be able to scale up pods quickly. I was learning a bit of spring last week and a spring boot web application, generated via the web interface boots in like 800msec: ... Initializing Spring embedded WebApplicationContext Root WebApplicationContext: initialization completed in 339 ms Tomcat started on port 8080 (http) with context path '/' Started DemoCourseApplication in 0.746 seconds (process running for 1.012) ... Reusing my experience from other technologies... I'd say the issue might be in whatever you're doing in your initialization and/or how much stuff you're loading. Looks like the core spring is decently fast, to me.
- conwaytwitty 2y ago
  depending on the size of the app, this can go from a few seconds locally, to 60 seconds when running on 1cpu nodes there's just so much being done during startup it requires some burst cpu
gf000 2y ago
Could you expand on "how bad the performance can be" part? If you are doing graphics, it is entirely more likely that you do something dumb there - there are many pitfalls. Also, unless you are doing something very CPU-heavy, there won't be any noticeable difference as web servers are doing IO predominantly. Maybe slightly less RAM usage (but you could also just decrease the heapsize to tradeoff a bit of CPU-time for memory, if it were to make sense).
- pylua 2y ago
  In my game loop I was using optional. When I profiled it the use of optional was one of the slowest points that could be optimized using null checks and ifs. There were a lot of other slow areas as well, not where you would expect it.
  - gf000 2y ago
    Sure, Optional is not the most optimal thing to use/do, though depending on how many entities you were operating with, that itself may still be negligible.
    - pylua 2y ago
      That’s the pain point - well written java code may not be the most performant depending on the situation. It wasn’t just optional but other areas as well.
      - gf000 2y ago
        That's not my experience, though game development is certainly a niche and Java may not be the top choice for that. You might sometimes have to reach for SoA-like structures and reference them via indices, at least for the core ECS, but for the rest you can easily use bog-standard Java -- not everything has to be "ultra-fast, specially written java", just certain hot loops.
        pylua 2y ago
conwaytwitty 2y ago
Spring Boot startup time is indeed a problem, especially when scaling horizontally on low cpu nodes. If your environment allows for burst cpu usage until ready to accept traffic, you can start up really fast as spring does so much reflection magic during startup that can't be done during compilation "trivially". You can include hints for runtime configuration from a build, but it doesn't do much to help in really low cpu envs. Then you can of course just do native images, but you lose some of the spring "magic", and might be annoying to refactor towards.
- pylua 2y ago
  I’ll have to look into burst cpu usage. Thanks
- ivan_gammel 2y ago
  This actually makes me wonder if it is possible to preserve post-startup state and then restore it as a way to mitigate long computational stage during startup. I bet it is, maybe we could just serialize the application context and restore it.
marginalia_nu 2y ago
Writing high performance Java is definitely a bit of a dark science, a lot of the performance isn't just the code loop you're looking at, but memory allocations matter quite a lot as well. Complex hierarchies of large long lived objects can absolutely tank your performance. There can also be a lot of performance to be gained by going off heap. I'd be probably be looking at an ECS design around MemorySegments, rather than modelling the game state with Java objects. Though, to be fair, this is how you'd write a game engine in C++ as well.

by pylua 2y ago

cmrdporcupine 2y ago

Most "microservice" backend type stuff is I/O bound, not CPU bound. You're likely not going to win much. Maybe get away with lower memory instances though.

rahen 2y ago
Cold latency is an issue with microservices. If you need to use Java, you'll likely end up using frameworks like Spring or Quarkus, which somewhat diminish the advantages of using the JVM and Java as a language. At that point, you might as well start with Go from the beginning.
- gf000 2y ago
  Is it really an actual issue? How often do you restart instances or scale up horizontally? A cheap 10 years old desktop PC can easily handle all the traffic a medium-sized website generates at all times.
  - pylua 2y ago
    What do you define as medium size?
    - gf000 2y ago
      Stackoverflow famously ran on a single, although quite beefy server PC for a long time (not any longer, but not for performance reasons AFAIK). I think it's a good data point to have to scale your workload to stackoverflow's, and reconsider the hardware costs. (Obviously horizontal scaling has its place, but if it's that variably scalable, maybe there are better solutions, e.g. a single bigger instance -- often times even for cheaper)
tugberkk 2y ago
why the downvote on this? is it wrong?

throwaway2037 2y ago

> I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze? So, replace cheap Java developers for expensive Rust devs to squeeze out some savings? It makes no sense to me.

tonyhart7 2y ago
well if the argument is cheaper, I can argue that JS/python dev would be more cheaper since there are more pool of talent
- throwaway2037 2y ago
  Double agree. If Java was the right choice 10-15 years ago for cheap enterprise apps, then certainly NodeJS is the way to go today. There are heaps of cheap developers and the ecosystem is ginormous.
  - pylua 2y ago
    Is it really to the point of challenging java ? Seems like Java is still the way to go here.

rootlocus 2y ago

Have you tried AoT compilation with graalvm?

pylua 2y ago
No, the product has a lot of aop and I figure it would be difficult to make that work.

znpy 2y ago

> The startup time is also a real problem, as you really want to be able to scale up pods quickly. I was learning a bit of spring last week and a spring boot web application, generated via the web interface boots in like 800msec: ... Initializing Spring embedded WebApplicationContext Root WebApplicationContext: initialization completed in 339 ms Tomcat started on port 8080 (http) with context path '/' Started DemoCourseApplication in 0.746 seconds (process running for 1.012) ... Reusing my experience from other technologies... I'd say the issue might be in whatever you're doing in your initialization and/or how much stuff you're loading. Looks like the core spring is decently fast, to me.

conwaytwitty 2y ago
depending on the size of the app, this can go from a few seconds locally, to 60 seconds when running on 1cpu nodes there's just so much being done during startup it requires some burst cpu

gf000 2y ago

Could you expand on "how bad the performance can be" part? If you are doing graphics, it is entirely more likely that you do something dumb there - there are many pitfalls. Also, unless you are doing something very CPU-heavy, there won't be any noticeable difference as web servers are doing IO predominantly. Maybe slightly less RAM usage (but you could also just decrease the heapsize to tradeoff a bit of CPU-time for memory, if it were to make sense).

pylua 2y ago
In my game loop I was using optional. When I profiled it the use of optional was one of the slowest points that could be optimized using null checks and ifs. There were a lot of other slow areas as well, not where you would expect it.
- gf000 2y ago
  Sure, Optional is not the most optimal thing to use/do, though depending on how many entities you were operating with, that itself may still be negligible.
  - pylua 2y ago
    That’s the pain point - well written java code may not be the most performant depending on the situation. It wasn’t just optional but other areas as well.
    - gf000 2y ago
      That's not my experience, though game development is certainly a niche and Java may not be the top choice for that. You might sometimes have to reach for SoA-like structures and reference them via indices, at least for the core ECS, but for the rest you can easily use bog-standard Java -- not everything has to be "ultra-fast, specially written java", just certain hot loops.
      - pylua 2y ago

conwaytwitty 2y ago

Spring Boot startup time is indeed a problem, especially when scaling horizontally on low cpu nodes. If your environment allows for burst cpu usage until ready to accept traffic, you can start up really fast as spring does so much reflection magic during startup that can't be done during compilation "trivially". You can include hints for runtime configuration from a build, but it doesn't do much to help in really low cpu envs. Then you can of course just do native images, but you lose some of the spring "magic", and might be annoying to refactor towards.

pylua 2y ago
I’ll have to look into burst cpu usage. Thanks
ivan_gammel 2y ago
This actually makes me wonder if it is possible to preserve post-startup state and then restore it as a way to mitigate long computational stage during startup. I bet it is, maybe we could just serialize the application context and restore it.

marginalia_nu 2y ago

Writing high performance Java is definitely a bit of a dark science, a lot of the performance isn't just the code loop you're looking at, but memory allocations matter quite a lot as well. Complex hierarchies of large long lived objects can absolutely tank your performance. There can also be a lot of performance to be gained by going off heap. I'd be probably be looking at an ECS design around MemorySegments, rather than modelling the game state with Java objects. Though, to be fair, this is how you'd write a game engine in C++ as well.