All good points. I've added notes about null terminating the strings, little endian byte order, and utf8 encoding.
zip or zlib or bzip compression may speed load time. I'm not sure, but I think that would be an iteration we add later. It probably wouldn't help with the theme .so file, but it might help with the locale .so. Seems like something we should profile later. On Mon, 8 Dec 2008, Adam Langley wrote: > > On Mon, Dec 8, 2008 at 10:40 AM, Evan Martin <[EMAIL PROTECTED]> wrote: > > - Is the plan to mmap the data file directly? Avoids copies, but > > means we should (a) null terminate the string resources (maybe the rc > > format does this already) and (b) sort the resource entries by > > resource id for faster lookup. > > Agreed, NUL terminating the strings is a good idea. Also, we should be > explicit that they are UTF-8 encoded where it matters. > > > - We should make explicit the byte order for the int32s. We can't > > support non-x86 anyway because of v8 but it'd nice if it would at > > least error out during the build on big-endian platforms. > > They should be unsigned, signed ints have no place as ids, sizes or > offets. They should be explicitly *little* endian since it's faster on > little endian machines and the same speed on most big-endian machines. > > > - Do we care about compression? (Trading off disk accesses for CPU > > and memory.) Why not a zip file? > > Given that text generally compresses well, this would be reasonable > although I don't feel strongly about it. Throw it via zlib if need be. > > > > AGL > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
