Files.readAllBytes(Path) is faster and more efficient than manually pulling bytes into the JRE's heap space #1

New issue

Closed

opened 2026-10-10 17:41:03 +02:00 by mkarg · 0 comments

mkarg commented

2026-10-10 17:41:03 +02:00

Happy to see that creating repositories on iJUG's Forge is working now. If you intend to keep this repository private, you need to explicitly do that. At the moment it is public.

Having said that, I like to tell you a small improvement. As you know, I was among the team that optimized OpenJDK's internal data logistics in the past years, and one of the tricks we frequently tell people is this: Don't write your own file loading loops, but use Files.readAllBytes(Path) instead. It is faster and more efficient. Why? Because within the JRE what we do here is that we first lookup the actual file size first, second tell the operating system (!) to read all that content in one single I/O call, and third wrap that native RAM buffer as a JRE heap byte[] last. In contrast, your current code imposes lots of I/O calls (which are very expensive and slow) and JRE-internal heap-to-heap copies when extending your 32k buffer (which is expensive and slow). HTH! 😃

try (var fis = Files.newInputStream(file)) {

Happy to see that creating repositories on iJUG's Forge is working now. If you intend to keep this repository private, you need to explicitly do that. At the moment it is public. Having said that, I like to tell you a small improvement. As you know, I was among the team that optimized OpenJDK's internal data logistics in the past years, and one of the tricks we frequently tell people is this: Don't write your own file loading loops, but use `Files.readAllBytes(Path)` instead. It is faster and more efficient. Why? Because within the JRE what we do here is that we first lookup the actual file size first, second tell the operating system (!) to read all that content in one single I/O call, and third wrap that native RAM buffer as a JRE heap byte[] last. In contrast, your current code imposes lots of I/O calls (which are very expensive and slow) and JRE-internal heap-to-heap copies when extending your 32k buffer (which is expensive and slow). HTH! 😃 https://git.ijug.eu/khmarbaise/duplicatefinder/src/commit/7e119c1121d016bf3db95ff09c5d630bfc8d553a/src/main/java/com/soebes/duplicate/CalculateHash.java#L48

mkarg changed title from ~~Files.readAllBytes(Path) is faster and more efficient that manually pulling bytes into the JRE's heap space~~ to Files.readAllBytes(Path) is faster and more efficient than manually pulling bytes into the JRE's heap space

2026-10-10 17:41:17 +02:00