In comp.lang.java.advocacy, Roedy Green
<see_website@[EMAIL PROTECTED]
>
wrote
on Tue, 01 Jul 2008 02:39:05 GMT
<146j64hrfa5evrkgmd6fg85a4i82u0je5l@[EMAIL PROTECTED]
>:
> On Tue, 24 Jun 2008 11:30:45 -0700, The Ghost In The Machine
> <ewill@[EMAIL PROTECTED]
> wrote, quoted or indirectly quoted
> someone who said :
>
>>I can do one better, though I rarely bother (I've seen
>>it done by a co-worker though); one can set up a virtual
>>memory area that is associated with a file, and then access
>>the area using char* pointers. The file load in this case
>>is done on an incremental basis, with pages faulting in as
>>needed. (mmap()/mmap2(), mremap(), munmap().)
>
> that would do well if you were processing only part of the file, but
> if you were processing every byte, then one giant i/o to read the whol
> thing would do better. Otherwise you could get a physical I/O per 2K
> or so, not even as good as a BufferedReader.
I'd frankly have to look, and it may depend on OS. Apart
from an optimization thing (if one open()s the file the OS
might assume readahead; mmap() might cause the OS to assume
entirely random), I don't see that much of a difference,
from a pure performance standpoint.
Then again, I've not done benchmarks.
Three other drawbacks, all roughly based on the system
I'm using internally (a template C++ affair):
[1] If one stores data structures in a file using mmap(),
one is obliged to ensure that the pointer returned by
mmap() is properly processed. In particular, if mmap()
returns a different pointer the structures won't work if
simple pointers are used. Two workarounds are possible:
offsets and self-relative pointers. Both are flawed.
A third solution would require a prepass and is rather
ugly; the old pointer is stored somewhere in the file and
all known pointers adjusted upon initial load.
[2] The workarounds in [1] extract additional processor
time; either one has to add to a base, or subtract two
pointers, when doing a dereference. Since one is "reading"
from a file anyway, this may not be a serious issue.
[3] The structures are by necessity processor-specific.
If a file is saved on an mk680x0 and loaded by an ix86,
conversion needs to happen. ASCII I/O doesn't have this
problem (though it has other issues).
--
#191, ewill3@[EMAIL PROTECTED]
memory has to be one of the most UNconventional
architectures I've seen in a computer system.
** Posted from http://www.teranews.com
**
|
