5 ms·
Citation needed. You make a lot of claims without evidence. Dropbox's experience https://dropbox.tech/infrastructure/lossless-compression-with-brotli https://d
by iscoelho 3y ago
Citation needed. You make a lot of claims without evidence.
Dropbox's experience https://dropbox.tech/infrastructure/lossless-compression-with-brotli https://dropbox.tech/infrastructure/lossless-compression-wit... shows a >10% performance difference caused by bounds checks in a similar context for a real world application. And before you say it: the Java JIT is not capable of optimizing bounds check elimination more than LLVM at this point in time. The JIT is not magical.
- pron 3y agoI think you misunderstand. There are cases where the performance hit would be significant, but there is absolutely no indication or reason to assume they're widespread. The JDK itself has switched away from Unsafe years ago (mostly except for cases it's not possible, but not due to performance, but technical reasons specific to the JDK alone) and performance overall has largely improved. In the special cases where there might be a performance hit, a single flag can take care of that, but we're concerned with improving the safety and performance of the ecosystem as a whole. If there's something that improves the average but harms some individual cases, we hide it -- as in this case -- behind a flag. Everyone who needs to be convinced that on average the benefit outweighs the cost has been convinced. It is those who think otherwise that would need to make a convincing case that on average Java applications will be harmed rather than helped.