11–20 of 25 posts
I imagine that there's going to be novice programmers whose takeaway from the article is "Hashmaps with ints as keys are slow" or "String concatenation in Java is slow".
String result = foo() + arg;
result += boo();
System.out.println(“result = “ + result);
I'm not sure 1. is relevant anymore. Almost all JVMs default to generational GCs, which would make all those allocations basically free.
Another: buy more RAM if needed, and set -Xmx###M and -Xms###M to sufficiently high numbers so that the JVM never runs out of memory and forces a collection. You can also do System.gc() to "suggest" a collection be done soon, such as while you're busy doing something slow that's I/O bound like reading a file or getting network data. Though I wouldn't be surprised if most of the time modern JVM GCs already know when y…
I'm not sure 1. is relevant anymore. Almost all JVMs default to generational GCs, which would make all those allocations basically free.
Earlier quoted context omitted.
The general advice is to produce less garbage. Strategies for doing so are specific to the language and APIs involved.
It's not just that you need to produce less garbage - you want to produce less live objects in general, as a large part of the cost during GC is determining which objects are live.
What you should do: allocate one read buffer with a capacity > expected length, overwrite-read into it, copy the data into a fresh capacity == actual length byte array, parse the copy, empty and reuse the read buffer.
What you definitely shouldn't do, despite it being tempting: allocate a read buffer each time and pass the whole thing around.
Currently the Java GC works splendidly with lots of short-lived, small immutable classes. Using this approach can be far better for performance than worrying about telling the ArrayList constructor how many elements the list will probably have.
"use streams instead of buffers" is completely wrong. It is much faster to read off a file or the network into a buffer rather than byte-by-byte so you can assume that anything which takes a stream, buffers it internally. What you should do: allocate one read buffer with a capacity > expected length, overwrite-read into it, copy the data into a fresh capacity == actual length byte array, parse the copy, empty and reu…
using (ByteBuffer buffer = pool.AllocateBuffer(128 * 1024))
{
// use buffer.array
}