At Tue, 9 Oct 2012 12:22:59 -0700, Dan Liebgold wrote:
On Tue, Oct 9, 2012 at 11:32 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 9 Oct 2012 18:00:14 + (UTC), Dan Liebgold wrote:
It still seems strange to me that we should implement our own
filesystem of some sort to get decent
On Wed, Oct 10, 2012 at 10:19 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
I guess we should try this, but I think we should keep it specific to
bytecode loading. That is, I don't think we should try to splice a
.zip-based filesystem into Racket's core filesystem operations.
I would think that
Just now, Matthew Flatt wrote:
I guess we should try this, but I think we should keep it specific
to bytecode loading. That is, I don't think we should try to splice
a .zip-based filesystem into Racket's core filesystem operations.
That's what I had in mind, though splicing a zip at the
On Wed, Oct 10, 2012 at 7:19 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
People who know about network filesystems tell me that the difference
is in how the filesystems are tuned. They think a single file to hold
bytecode will likely help by trading meta-data operations on many files
for
FWIW, a zip file may not be a good format because the file index is
just a O(n) access list (no matter how many sub-directories the zip
file contains.) I didn't find any standard archive formats with O(log
n) or better performance, which is why DrDr uses a custom format:
At Tue, 9 Oct 2012 18:00:14 + (UTC), Dan Liebgold wrote:
Now is there a way to archive the bytecode files in general (thinking .jar
files), and the standard collects in particular? Right now our app will stat
and load thousands of .zo files during it's normal operation. In performance
6 matches
Mail list logo
