It seems like loading into memory will result in more predictable access
times for the initial set of words that get spellchecked (up to the point
where the memory-mapped file would have been entirely paged in). If you
combine this with my memory purger code that will (hopefully) result in the
There's also option 3)
Pre-fault the mmap()ed region in the file thread upon dictionary
initialization.
On Linux at least, that may give you better behaviour than malloc() + read()
in the event of memory pressure.
Cheers
Chris
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org
If you plan to read the entire file, mmap()ing it, then faulting it in will
be slower than read()ing it, at least in some Linux versions. I never
pinned down exactly why, but I think the kernel read-ahead mechanism works
slightly differently.
--
Steve
On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans
On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans cev...@chromium.org wrote:
There's also option 3)
Pre-fault the mmap()ed region in the file thread upon dictionary
initialization.
On Linux at least, that may give you better behaviour than malloc() +
read() in the event of memory pressure.
On
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote:
Hi all,
At its last meeting the jank task force discussed improving
responsiveness of the spellchecker but we didn't come to a solid
conclusion so I thought I'd bring it up here to see if anyone else has
opinions. The
On Linux what about mmap() and then madvise() with MADV_WILLNEED? [or
posix_fadvise() with POSIX_FADV_WILLNEED on the file descriptor).
-scott
On Thu, Oct 22, 2009 at 2:06 PM, Steve Vandebogart vand...@chromium.org wrote:
If you plan to read the entire file, mmap()ing it, then faulting it in
On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote:
Hi all,
At its last meeting the jank task force discussed improving
responsiveness of the spellchecker but we didn't come to a solid
On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson bre...@chromium.org wrote:
This doesn't help on Mac where we want to use the system spellchecker.
FYI, we got a patch to use the system spellchecker on Linux as well.
http://code.google.com/p/chromium/issues/detail?id=24517
I should probably ping
It's been awhile since I looked at this, but the email I was able to dig up
suggests that madvise is no faster than faulting in the mmap()ed region by
hand. However, using posix_fadvise should give the same speeds as read()ing
it into memory. IIRC though, posix_fadvise will only read so much in
Faulting it in by hand is only helpful if we're right! If we're
wrong, it could evict other stuff from memory to support a feature
which a user may not use until the memory is faulted back out anyhow.
[From the rest of the thread, though, it sounds like maybe we should
just fix hunspell to be
+1 on moving spell to the renderers.
We can memory map in the browser and map again the in renderers.
Hopefully read-only.
We eliminate the sync ipc and do not increase the memory usage.
On Oct 22, 2:42 pm, Steve Vandebogart vand...@chromium.org wrote:
It's been awhile since I looked at this,
Probably a bit off topic at this point, but but your response confuses me
- MADV_WILLNEED and POSIX_FADV_WILLNEED will bring the pages into ram, just
like faulting in mmap()'ed pages by hand, or read()ing it into memory. In
my experience, read() and fadvise() are faster than mmap()+faulting
WILLNEED says Hey, OS, I think I'm going to look at these pages soon,
get yourself ready, but the OS could implement them as a nop, and can
do it async. If memory is under pressure the system can do less, if
memory is clear it can do more. Actually reading the data into memory
blocks and
That is the intention of the interface yes, but all Linux implementations
I've seen actually go and read what ever you say you will need. Of course
with a few exceptions like actually being out of memory.
--
Steve
On Thu, Oct 22, 2009 at 3:06 PM, Scott Hess sh...@chromium.org wrote:
WILLNEED
14 matches
Mail list logo
