3 ms·

Sorry if my comments don't agree with you. I work on a system that takes in multibillion hits a day so do know a little about this argument. What's your backg

Sorry if my comments don't agree with you. I work on a system that takes in multibillion hits a day so do know a little about this argument. What's your background? We use lots of caches to improve our speed but caching doesn't really do well for generational GC's. I do see realtime GC's on the far horizon but currently it's been on the academic front.

DrJokepu 17y ago
While I haven't worked on any project demanding this kind of scalability, I'm struggling to believe that garbage collection would be a bottleneck here. Modern managed environments these days are ridiculously fast and the garbage collectors are shockingly efficient. It's not 1994 anymore. I think they are more likely to have performance issues because of the dozens of complex webservice xml-rpc calls that are required just to get a simple piece of data (as it is usual in enterprise systems).
- mfairview 17y ago
  Systems can get large enough that it would take a few seconds for GC to complete thereby causing unacceptable latency (especially if you need to meet strict SLAs). Consider a caching datastructure that needs to be constantly updated with fresh data. Objects in the cache remain there long enough to get into the final generation only to be pulled off some time later. Without memory management (e.g. object pooling for one), you'd quickly fill up your long lived generation causing the system to repeatedly want to reclaim.
eru 17y ago
No offense taken. I was just arguing from an academic point of view. In the real world stuff is often much hairier, and if you can make C (or whatever you are using) to behave nicely, that's good for you. (I do not like Java either. Perhaps you should check out Ocaml? It's a nice and fast functional programming languages. The high-frequency traders at Jane Street Capital are quite fond of it. And I guess they are not too tolerant of delays.)

DrJokepu 17y ago

While I haven't worked on any project demanding this kind of scalability, I'm struggling to believe that garbage collection would be a bottleneck here. Modern managed environments these days are ridiculously fast and the garbage collectors are shockingly efficient. It's not 1994 anymore. I think they are more likely to have performance issues because of the dozens of complex webservice xml-rpc calls that are required just to get a simple piece of data (as it is usual in enterprise systems).

mfairview 17y ago
Systems can get large enough that it would take a few seconds for GC to complete thereby causing unacceptable latency (especially if you need to meet strict SLAs). Consider a caching datastructure that needs to be constantly updated with fresh data. Objects in the cache remain there long enough to get into the final generation only to be pulled off some time later. Without memory management (e.g. object pooling for one), you'd quickly fill up your long lived generation causing the system to repeatedly want to reclaim.

eru 17y ago

No offense taken. I was just arguing from an academic point of view. In the real world stuff is often much hairier, and if you can make C (or whatever you are using) to behave nicely, that's good for you. (I do not like Java either. Perhaps you should check out Ocaml? It's a nice and fast functional programming languages. The high-frequency traders at Jane Street Capital are quite fond of it. And I guess they are not too tolerant of delays.)