[racket] Rackets memory usage
At Thu, 26 May 2011 21:02:35 +0100, Jimmy Coyne wrote:
> I do have some concerns when it comes to memory requirements
> however. On Windows if I run a simple GUI program using code from the Racket
> Windows tutorial where a dialog box is shown with a push button (1.1
> Creating windows), the private working set is 70 Megs , which is very large
> for such a small program.
>
> These exe was created by DrRacket “Create Executable ”. Am i doing
> something wrong?
No, I think we have some work to do to improve Racket's memory
footprint.
I see about 70 MB for a 64-bit Windows build or a 32-bit Mac OS X build
using the latest development version of Racket. A similar Java program
with Swing seems to take about 40 MB under Mac OS X in 64-bit mode.
Just to make sure, since memory use varies considerably among recent
versions and platforms, can you say more about which version and
platform (64-bit vs. 32-bit) you're using?
For example, I see a 70 MB working set under 64-bit Windows with the
latest development version, but I see about half that for 32-bit
Windows and version 5.1.1. For 32-bit Mac OS X, I see about a 70 MB
footprint for 32-bit development version, 95 MB for 64-bit development
version (and no significant difference for Cocoa vs. X), and 45 MB for
32-bit version 5.1.1.
The version difference has to do with new support for "places", which
reserves extra memory for communication among parallel tasks. The
Windows build tends to be more compact overall due to differences the
virtual memory API. A lot of memory use is the big language that you
get from `racket' as opposed to the core `racket/base'. Finally, some
memory goes into the new GUI toolkit, as opposed to the old GUI binding
of v5.0.2 and earlier.
latest latest v5.0.2
no places places [no places]
racket -l racket/base 8 MB 25 MB 8 MB
racket -l racket 22 MB 38 MB 20 MB
racket -l racket/gui/base 41 MB 55 MB 30 MB
racket -l racket/gui 48 MB 68 MB 36 MB
Jay and Blake (@ BYU) are working on a whole-program compiler that can
shrink stand-alone executes by throwing out code that you don't use,
which will help solve problems with the big `racket' language. Kevin
and I should look more into limiting the cost of support for places
when places are not used. I should look into whether the new GUI
library is using more memory than necessary.