Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Wojtek Newsgroups: comp.lang.java.programmer Subject: Re: The first 10 files Date: Fri, 15 Mar 2013 10:31:59 -0700 Organization: A noiseless patient Spider Lines: 47 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15"; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: mx05.eternal-september.org; posting-host="913a58905027d5a3bf7c700d71b3a757"; logging-data="19521"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9ZXcDFsffOtj+epPgPkBU7I2e/3pkoY0=" X-Newsreader: MesNews/1.08.03.00-gb Cancel-Lock: sha1:hSfKhMcxFXOrT6vgYM+3BTN/D1E= Xref: csiph.com comp.lang.java.programmer:22960 Robert Klemme wrote : > On 14.03.2013 11:07, Wojtek wrote: > >> So NIO is about 4-5 times faster than IO. The first NIO run looks like >> an anomoly, might be some JRE loading happening. >> >> All the runs produce different timings, might be a Windows caching >> effect. However the NIO is consistently much faster overall. > > I am not convinced that this conclusion is warranted. There are a few > factors which I believe make your conclusion questionable: > > - You included class loading time in your measurement. For example, assuming > that all io functionality is implemented on top of nio it would be logical to > expect more classes to be loaded. There are a number of use cases where it > matters - but there are also use cases where it doesn't matter (long running > servers). The class loading would be part of a real project. The alternative is to keep an object around which holds a link to a directory. Actually many objects linked to many directories. Also the file list will change as files are added and deleted. > - Generally we are dealing with quite low timings (around 100ms) and > relatively high variations. Also the test was made on Windows and the > System.currentTimeMillis() is known to be imprecise on that platform (in the > order of tens of milliseconds). Fair enough. > - Your io approach does not use FileFilter which some have suggested to be a > way to avoid constructing a large result array. Yes, but to filter the result still means loading each file name, then checking to see if it matches the filter. > - The test is an artificial situation. With all factors like JVM involved it > may be that in a realistic application things look different to an extent > that the differences you measured here do not matter any more. While the absolute times may be questionable, the relative times are consistent. -- Wojtek :-)