User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
Hi Greg,
Greg Guerin wrote:
> Dan Creswell wrote:
>
>
>>FileInputStream read 8M (avg) 6
>>FileInputStream read 8M (mean) 7
>
>
> That's over 1 GB/s. Pretty impressive. It'd be more impressive if it were
> really reading a hard disk instead of a RAM cache.
>
>
> All the results I've seen so far indicate that either:
> - writing a file and then reading it, or
> - reading a file more than once,
>
> ends up mainly testing the speed and/or capacity of the OS's disk cache.
> It probably also shows the limiting speed for read() on any file, since
> getting data from storage in the first place can only increase the elapsed
> time. That is, cache is reducing the actual "fetch data from storage" time
> to zero, which is certainly the best case possible.
>
[snip]
On the technical level I believe you are correct but that I think it's
only a small part of the overall issue.
The trouble is that each OS is exhibiting different policies and a naive
user is unaware of these different policies leading to assumptions about
performance as perhaps demonstrated by this thread. Equally, the
original poster may actually be hitting a performance issue. How do we
know which it is?
Either way, we have to start developing some "tools" to dig at these
issues across OS'en so's we can provide an accurate answer when these
questions come up.
The above test results, therefore, are interesting because it suggests
that Linux aggressively caches recently written data whilst OS X is more
resistant - the question would be, when is each policy useful and why?
This information then needs posting and understanding by developers.
Something which I think all the test data (and some of your comments)
will achieve.
[snip]
> On file-writes, it seems closing or flushing a FileOutputStream
> doesn't necessarily write all the data to the storage medium at that
> time. The test was interesting in that creating 25 files of 1 or 2 MB
> was quite fast, a few seconds. Yet a subsequent 'sync' at the
> command-line then took 30 seconds or so to finish, and Activity
> Monitor.app showed disk writes. There's clearly an asynchronous
> disk-write cache, as expected from a Unix-like system.
[snip]
Indeed there is and, for various applications this feature is useful.
However, for databases it's not so useful as they sync more often and
the sync speed across operating systems varies wildly. Thus a complete
set of tests might have to cover all these eventualities and we should
be exposing tuning knowledge in all areas.
In conclusion, whilst I think your points are valid your delivery comes
across somewhat aggressive (whether you intend it or not) which can turn
people off to the point where they won't listen to anything we say
whether it's right or wrong. It can also have a de-motivating effect on
those trying to move things forward (like Michael McDougall).
Kindest Regards,
Dan.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
