Thank you for taking the time to reply to my original "issue".
"1) Please specify the OS version. The behavior of file systems and the JRE is quite different among Unix and Windows. I am running the following code on Mac OS X 10.9.2, Oracle JDK 1.7.0_51-b13."
I'm running JDK 7u51 on Windows 7.
"2) The JVM optimizes hot spots at run time, so for a real benchmark please wrap the test in another loop to compensate for JVM warm up time."
True for actual benchmarking, though in this case what happens after "TVFS.umount();" is the interesting part.
"3) In production, please make sure to ALWAYS close your streams, even in case of a throwable, e.g. within a finally block or with a try-with-resources statement."
"4) For comparable results, you must delete the archive files before the test runs because TrueZIP behaves differently depending on whether the archive file already exists or not."
The code was intended ONLY as an example; it reproduces the "slowness" which I'm experiencing in the actual code but is short enough to serve as an example (as error handling, etc. is left out). For me it was obvious that the code I posted was not intended as anything else than a quick and dirty example, but I guess I should have mentioned that (and especially the part where the created files should be deleted after running the code).
"Now here is the simple solution: You have introduced superfluous calls to TFile.createNewFile() and Files.createFile(TPath). These calls have side effects, and in the case of Files.createFile(TPath), when looping over an archive file this results in quadratic runtime, which is what you were witnessing."
Indeed, the calls are superfluous. But without them, the issue is not reproducible. That's why I stated in my original post: "Using TPath is at least twice as slow as TFile when each file in an archive is created before the contents is written". The question was therefore why this makes such a huge difference (as using TFile.createNewFile() has a negligible impact on performance)?