How fast is ClassGraph

ClassGraph is the fastest classpath and module scanning mechanism:

• ClassGraph parses the classfile binary format directly to determine the class graph. This is significantly faster than reflection-based methods, because no class has to be loaded to find out how classes are related. Static initializer blocks are not run either, which saves time and avoids their side effects.
• ClassGraph implements its own highly-optimized bytecode parser, and does not depend upon large, abstract bytecode parsing libraries like ObjectWeb ASM. In fact, ClassGraph has no external dependencies at all -- the only things it depends on are its own sibling libraries, classgraph-base, classgraph-vfs and classgraph-classpath.
• The classgraph-vfs library implements its own highly-optimized zipfile central directory parser, which is capable of handling jarfiles nested within jarfiles, to arbitrary nesting depth, without first extracting the inner jarfile (as long as the inner jarfile is stored rather than deflated). (The Java ZipFile API is not capable of this.) It also takes no locks to look up or read an entry, whereas java.util.zip.ZipFile serializes every one of its public methods on the instance monitor, so a single ZipFile cannot be read in parallel. This library is a read-only virtual filesystem over directories, jarfiles and modules alike, and can be used on its own, without ClassGraph -- see the Vfs API.
• ClassGraph has been carefully profiled, tuned and parallelized so that multiple threads are concurrently engaged in reading from disk/SSD, decompressing jarfiles, and parsing classfiles. Consequently, ClassGraph runs at close to the theoretical maximum possible speed for a classpath scanner, and scanning speed is primarily limited by raw filesystem bandwidth.
• Wherever possible, lock-free datastructures are used to eliminate thread contention, and shared caches are used to avoid duplicating work. Recyclers are used to avoid allocating more objects than necessary, and to avoid repeating the overhead of opening jarfiles and modules.
• Packages, classes, jarfiles and modules can be accepted or rejected, so that only the resources you need are scanned.
• ClassGraph reads jarfiles through an NIO FileChannel, memory-mapping the file on Windows and using positioned channel reads everywhere else. There is nothing to configure and no tuning to get wrong: the choice is made for you, and is backed by measurements on all three platforms, published in full in the memory mapping benchmark. Mapping is used where it is faster, which is Windows alone -- on Linux it can be slower, and on macOS it is inside the noise. ClassGraph also only reads as many bytes as necessary from a classfile to get the required class metadata.

ClassGraph is typically several times faster at scanning large classpaths consisting of many directories or jarfiles than the widely-used library Reflections. If ClassGraph is slower than Reflections for your use case, it is because ClassGraph found a larger set of classpath elements to scan. You can limit what is scanned with the accept and reject methods.