3 ms·
I'm super-reluctant to go this way because it's often a bug factory. Once you are expecting the programmer to do manual GC and detect when a buffer can be reus
by ErikCorry 4y ago
I'm super-reluctant to go this way because it's often a bug factory. Once you are expecting the programmer to do manual GC and detect when a buffer can be reused you are losing some of the benefit. A lot of the time the answer should a better GC and a smarter compiler. I realize that in practice that's not always available.
- chrsig 4y agoI want to say that it should only be used after profiling and determining that it's a major cause off GC pressure, however I think there are other times when it's obvious that a private scratch buffer would be appropriate. For example, when marshaling an object before writing it to a file, makes sense to write it to a scratch buffer before writing it to the file. It's generally on the order of trivial to keep said buffer encapsulated to prevent any caller from dealing with potential pitfalls. Having clear ownership of the buffer is a big benefit to help reduce any potential issues. You're correct that as a GC approaches perfect, there ceases to be a need for it.