Uses a "flat" files model to store the cached instrumented classes and aspects - i.e., each class/aspect is stored as a separate (binary) file. This is a good mechanism when the number of instrumented class is relatively small (a few 10's). The reason for it is that scanning a folder that has many files in it quickly becomes an I/O bottleneck. Also, some O/S-es may impose internal limits on the maximum number of "children" a folder node may have. On the other hand, it is much faster (again, for small number of instrumented classes) than the ZIP cache since each class/aspect is represented by a single file - thus adding/removing/modifying it is easier.