2008/10/10 Thomas Schilling <[EMAIL PROTECTED]>:
> 2008/10/10 David Waern <[EMAIL PROTECTED]>:
>> I resorted to strictness annotations in the Interface structure since
>> I didn't want Haddock to pretty print everything.
>
> Do you think depSeq on GHC's output would help? IIUC, Haddock
> processes
2008/10/10 David Waern <[EMAIL PROTECTED]>:
> I resorted to strictness annotations in the Interface structure since
> I didn't want Haddock to pretty print everything.
Do you think depSeq on GHC's output would help? IIUC, Haddock
processes each file immediately and only retains information in
Int
2008/10/10 Thomas Schilling <[EMAIL PROTECTED]>:
> Peak memory usage seems to be around 550MB now, which may just be
> below the threshold to swapping for 32 bit systems with 1GB RAM. It's
> probably worse on 64 bit systems, though.
I resorted to strictness annotations in the Interface structure
Peak memory usage seems to be around 550MB now, which may just be
below the threshold to swapping for 32 bit systems with 1GB RAM. It's
probably worse on 64 bit systems, though.
2008/10/10 Simon Marlow <[EMAIL PROTECTED]>:
> David Waern wrote:
>>
>> 2008/10/9 David Waern <[EMAIL PROTECTED]>:
>>>
David Waern wrote:
2008/10/9 David Waern <[EMAIL PROTECTED]>:
I've now managed to reduce memory usage from 1000 M to 350 M at its
peak when processing the ghc package, by interleaving typechecking
with interface creation. I use pretty printing to fully evaluate the
Interface structure at each ro
2008/10/9 David Waern <[EMAIL PROTECTED]>:
> I've now managed to reduce memory usage from 1000 M to 350 M at its
> peak when processing the ghc package, by interleaving typechecking
> with interface creation. I use pretty printing to fully evaluate the
> Interface structure at each round.
Getting
So, the status on this:
Thomas submitted working code to GHC's Haddock repository for
typechecking all modules without loading things twice.
I've now managed to reduce memory usage from 1000 M to 350 M at its
peak when processing the ghc package, by interleaving typechecking
with interface creati
2008/10/7 Simon Marlow <[EMAIL PROTECTED]>:
> I think you're missing the topSortModuleGraph. For an (old) example, look
> in utils/ghctags. It is using checkAndLoadModule, but you should be able to
> replace that with parseModule/typecheckModule/loadModule.
I didn't look at this much, but if I a
David Waern wrote:
2008/10/4 Thomas Schilling <[EMAIL PROTECTED]>:
'loadModule' now takes a ModSummary which should be enough to emulate
checkAndLoadModule with the new API. It's in head and should be in
stable soon.
So how do I use this? Can you paste a snippet of code that, given a
list of
2008/10/4 Thomas Schilling <[EMAIL PROTECTED]>:
> 'loadModule' now takes a ModSummary which should be enough to emulate
> checkAndLoadModule with the new API. It's in head and should be in
> stable soon.
So how do I use this? Can you paste a snippet of code that, given a
list of files (or module
'loadModule' now takes a ModSummary which should be enough to emulate
checkAndLoadModule with the new API. It's in head and should be in
stable soon.
2008/9/30 David Waern <[EMAIL PROTECTED]>:
> 2008/9/30 Simon Marlow <[EMAIL PROTECTED]>:
>>>flag <- load LoadAllTargets
>>
>> This is a problem
2008/9/30 Simon Marlow <[EMAIL PROTECTED]>:
>>flag <- load LoadAllTargets
>
> This is a problem. You're loading all the modules twice: once in the line
> above, and once again when you typecheck each module below.
Oh, sorry! I should have remembered this problem. I wonder why I never
switched
David Waern wrote:
2008/9/30 David Waern <[EMAIL PROTECTED]>:
Here's the reduced program:
Sorry, here's the correct version (it got messed up during copy-paste):
(mkGhcModule is a complete no-op, it just creates a record out of some
of the typechecking results)
main :: IO ()
main = handleTop
2008/9/30 David Waern <[EMAIL PROTECTED]>:
> Here's the reduced program:
Sorry, here's the correct version (it got messed up during copy-paste):
(mkGhcModule is a complete no-op, it just creates a record out of some
of the typechecking results)
main :: IO ()
main = handleTopExceptions $ do
--
At a guess, I'd say Haddock is probably accidentally retaining the whole
typechecked syntax for every module.
Cheers,
Simon
Thomas Schilling wrote:
I measured on OS X the other day. Peak was at about 700 MB (on a 32
bit system, it's probably even more on 64 bit). Simon M said there
u
I measured on OS X the other day. Peak was at about 700 MB (on a 32
bit system, it's probably even more on 64 bit). Simon M said there
used to be a memory usage bug in --make mode, because interface files
were retained for too long; this could be related.
On Thu, Sep 18, 2008 at 9:53 PM, Thorkil
2008/9/18 Thorkil Naur <[EMAIL PROTECTED]>:
>> I wonder wether this is an OpenBSD specific bug, just an ordinary
>> memory leak, or Haddock really needing that much memory.(I'll just
>> disable haddocking for now to proceed with testing)
>
> OpenBSD-specific it is not.
>
When I ported Haddock I di
Hello,
On Thursday 18 September 2008 20:37, Matthias Kilian wrote:
> Hi,
>
> does anyone else see haddock using huge amounts of memory (more
> than 640MB) when building ghc-HEAD? It's always running out of
> memory for me when haddocking the compiler itself (i386, OpenBSD,
> datasize limit is set
Hi,
does anyone else see haddock using huge amounts of memory (more
than 640MB) when building ghc-HEAD? It's always running out of
memory for me when haddocking the compiler itself (i386, OpenBSD,
datasize limit is set to 640MB):
gmake[1]: Entering directory `/var/tmp/ghc/ghc/compiler'
/var/tmp/g
19 matches
Mail list logo
