Comment by jaawn | Hacker News Reader

Comment by jaawn | Hacker News Reader

Parent Full thread

This is exactly the kind of "programming by coincidence" discussed at the link I provided.

If you are designing something that makes heavy use of String and String operations, and you know it needs to be as optimized as possible, you should consider whether or not you need a custom String solution as part of the design process. Of course there is a hypothetical scenario where a developer might run into this even when "doing everything right", but generally it can be avoided by being aware of these potential interactions and "program deliberately."

I am not saying there will never be times when you need to "just make it work" and reasonably can't account for everything like this. The real world does not always provide the opportunity to do everything "the right way." My point is just that, when you run into this issue, it should be understood that any issues caused by implementation changes aren't really the fault of the maintainers if they haven't broken the contract/interface, and it performs well under the use cases it is designed for.

> If you are designing something that makes heavy use of String and String operations, and you know it needs to be as optimized as possible, you should consider whether or not you need a custom String solution as part of the design process.

And how do you do that? By writing a test case and seeing what the standard string does. Clearly, we expect things to change over time, so Oracle didn't necessarily do something underhanded here. But Oracle did change the behavior of String enough that people need to hear about it, and perhaps reconsider whether the standard string still does what they need to do.

One method would be to have an informal heuristic you use when you're about to call a library: are the performance characteristics I need guaranteed by this library? If yes: proceed, if no: use a different solution or proceed with caution.

So, if you are implementing something that deals with a large input string, and creates a large number of substrings, you know there could potentially be a performance impact depending on the way the implementation works with substrings. The API makes no performance or memory guarantees about substrings. If your application has strict performance requirements, you know you either need to find another solution, or "proceed with caution."

In this case, performance shouldn't have changed much -- at least in a big-O sense -- but memory use did. And the JDK guys have been swearing for years that the garbage collector handles that for you, so I'm not sure alarm bells would have gone off.

(We'll ignore the fact that every article I see about high performance Java talks about using memory buffers or some kind of "off heap" scheme specifically to get around the garbage collector).

I need a random number. I see that Java has a class for this ( http://docs.oracle.com/javase/8/docs/api/java/util/Random.ht... ). It doesn't guarantee anything about performance. It doesn't even really guarantee anything about the algorithm it will use in the future, but does say that it currently uses a linear congruential algorithm. Should I (1) write my own random number generator? (2) "proceed with caution"? or (3) write a test case, see if the thing is fast enough for what I want, and pay attention to any changes to java.util.Random in future releases? Personally, I generally pick (3).

I would usually choose option 2 or 3, but that is because usually small performance discrepancies are unimportant. If performance is paramount at the point in the code where the library is used, I would opt for (1) or a fourth option you omitted: find a library which has already implemented a performance-driven solution.

It is similar to sorting implementations. If you have a small list of items in a collection, you might not care about how fast they can be sorted as long as it is "reasonably fast," so you can just use a built-in sort() function. If you know your collection will likely be larger than most, or you need them sorted as fast as possible, you might choose to implement your own sorting function, or use a different library which specifies a given performance level.

You could just use this hypothetical, built-in sort() for now, and deal with it later if any issues arise, or you could plan ahead if it is important and future proof the code now. The former would be "proceeding with caution" while the latter would be the more maintainable, "best practices" approach when you know performance is higher priority than normal.

If you "proceed with caution" you might run into a situation where the maintainers switch from insertion sort to heap sort, because in many (most?) use cases, heap sort is faster. However, your collection is often already sorted or mostly sorted, which is a case where heap sort performs much worse than insertion sort. Now your specific application has worse performance, but other applications have improved performance. If your collection needs to be sorted at a specific performance level, it is better (but not required) for you to implement a custom sort function, or use a library that is designed for your use case. This way you can have appropriate control over the performance.

Reply on news.ycombinator.com