Hello,
Andy Wingo skribis:
> On Wed 25 Oct 2017 19:42, l...@gnu.org (Ludovic Courtès) writes:
>
>> In short, compiling the top-level thunk is what’s killing us, because
>> the space and time complexity is proportional to the number of labels
>> therein.
>>
>> Also, our 16K line python.scm file t
On Wed 25 Oct 2017 19:42, l...@gnu.org (Ludovic Courtès) writes:
> In short, compiling the top-level thunk is what’s killing us, because
> the space and time complexity is proportional to the number of labels
> therein.
>
> Also, our 16K line python.scm file translates into 428K labels, which
> du
Hello,
An update on this…
l...@gnu.org (Ludovic Courtès) skribis:
> This is a followup to the compiler issue, this time focusing on
> execution time, trying to see why the compiler takes so long to compile
> gnu/packages/*.scm, which should be trivial.
>
> As a test bed, I built this from the G
Hello,
This is a followup to the compiler issue, this time focusing on
execution time, trying to see why the compiler takes so long to compile
gnu/packages/*.scm, which should be trivial.
As a test bed, I built this from the Guix tree:
GUILE_LOAD_COMPILED_PATH=$PWD guild compile \
-L $PWD
Heya,
Andy Wingo skribis:
>> Also, for reference, loading python.go peaks at 315M RSS:
>>
>> $ \time ./pre-inst-env guile -c '(use-modules (gnu packages python))'
>> 0.18user 0.02system 0:00.18elapsed 112%CPU (0avgtext+0avgdata
>> 315648maxresident)k
>> 0inputs+0outputs (0major+7784minor)pagefa
Hi!
Definitely sounds like we have an issue we should deal with.
On Tue 16 May 2017 18:19, l...@gnu.org (Ludovic Courtès) writes:
> here is the gcprof output
I find gcprof useful when I want to improve runtime by removing
allocation. However I don't find it useful when dealing with memory use
