From: Dan Liebgold (dan.liebgold at gmail.com)
Date: Tue Oct 9 15:22:59 EDT 2012

On Tue, Oct 9, 2012 at 11:32 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> At Tue, 9 Oct 2012 18:00:14 +0000 (UTC), Dan Liebgold wrote:
> It still seems strange to me that we should implement our own
> filesystem of some sort to get decent filesystem performance.
Indeed. I think in game development we tend to be a bit nuts about
performance, but I do have some numbers to back it up!

During a single startup of our app we trigger about 7000 file operations in
the collects directory. When stored on a local hard drive it takes about 2
seconds. On a network drive that number climbs to about 30 seconds. And
that is just loading the collects we utilize.

We invoke Racket about 1500 times every time we build one of our game
projects, and currently we have about 4-6 automated builds plus 20
programmers building as well. (You can probably only imagine how much we
depend on precompiled headers on the C++ side of our projects.) The numbers
climb quickly. So accessing over the network is too slow.

Now it turns into a bit of a distribution problem. We have 150+ people
in-house that need to run this, plus 50 or so more outsourced in various
locations around the country. The standard Racket distro contains about
13,000 files. That many copies and syncs gets quite awkward, although it

Ideally we would have a handful of executables and archives to distribute
and utilize. Also ideally, the archives would contain just .zo files (or
something equivalent.)

Now I realize that we are the ones who must lay the track in front of this
speeding freight train, so we are willing to do what it takes to implement
this... just point me in the right direction!

BTW, when I selected MzScheme for this project back in '05 I had no idea
both what our production would look like at this point nor how well
MzScheme would operate under these constraints. And Racket is improving
upon it in every way!

Dan Liebgold    [dan.liebgold at gmail.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121009/dd7a1650/attachment.html>

Posted on the dev mailing list.