StartupCache: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
* Index of entries in the file(at the end of it) | * Index of entries in the file(at the end of it) | ||
* Per entry-checksum like jars | * Per entry-checksum like jars | ||
* No multiplexing, writing to the cache will write into a memory buffer and it will be serialized on .Close() | * No multiplexing, writing to the cache will write into a memory buffer and it will be serialized on .Close() (one close() per module). | ||
* Single mmaped cache file to reduce file io | * Single mmaped cache file to reduce file io | ||
* Will be suitable for everything that's currently stored in fastload + manifest cache + pref cache + etc | * Will be suitable for everything that's currently stored in fastload + manifest cache + pref cache + etc | ||
Revision as of 18:36, 6 October 2009
StartupCache is a replacement for Fastload.
It is meant to reside in the profile directory and provide a convient API to store continious chunks of data in it.
I think we can use the JAR format for this
Things I want:
- Index of entries in the file(at the end of it)
- Per entry-checksum like jars
- No multiplexing, writing to the cache will write into a memory buffer and it will be serialized on .Close() (one close() per module).
- Single mmaped cache file to reduce file io
- Will be suitable for everything that's currently stored in fastload + manifest cache + pref cache + etc
- Cache should have a string table that cache's consumers can share.
Cache's filename should be:
startup.<endianness>.<wordsize>.cache to avoid issues with people moving profiles between machines
We hope to achieve some performance wins by having 1 file and contiguous buffers. Also, hopefully we can cache more stuff.
Proposed interface is just char* getBuffer(id), writeBuffer(id, buf, length). Clients take care of their own serialization/deserialization.