I'd rather like that too.
Also to be able to reset it.
On Fri, Apr 3, 2015 at 1:05 AM, Mark Wotton wrote:
> https://ghc.haskell.org/trac/ghc/ticket/10235#ticket
>
> Would be really useful to be able to profile code without dying,
> especially in the context of a long-lived server. Am I missing
https://ghc.haskell.org/trac/ghc/ticket/10235#ticket
Would be really useful to be able to profile code without dying, especially
in the context of a long-lived server. Am I missing something that would
allow me to do this?
cheers
mark
___
Glasgow-haskel
Great sleuthing!! Thanks for pinning down whats going on!
On Apr 2, 2015 8:48 PM, "Thomas Miedema" wrote:
> Jeremy,
>
> On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema
> wrote:
>
>> Maybe `split-objs` is not applied?
>>
>
> That suggestion was completely misguided. Compiling with `-split-objs`
>
Jeremy,
On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema
wrote:
> Maybe `split-objs` is not applied?
>
That suggestion was completely misguided. Compiling with `-split-objs`
makes a library _grow_ in size, but makes executables that link against it
_smaller_.
Size of `libHSCabal-1.22.2.0` obtain
In a 64-bit machine with Ubuntu 12.04 and 4 GB of RAM, I can compile
Agda using GHC 7.10.1 without problems. Agda's compilation time
increased ~26% with respect to GHC 7.8.4.
On 2 April 2015 at 07:19, Jan Stolarek wrote:
> An update frrom my second machine, this time with 4GB of RAM. Compiling A
I have run out of memory before when compiling on small machines using GHC 7.8,
where small machines have 4GB RAM, no swap, say small Dual Core Atom, almost
embedded design. That forced me to compile on a laptop and mount file systems
to run it. But since Ubuntu runs well on a NUC, it is nice to
> I'm curious why the amount of RAM is relevant as all of our OS have virtual
> memory so it is only the size of the heap and the amount of swap that
> should be relevant for an Out Of Memory error, right? How big is your heap?
> Amount of RAM should only affect speed (i.e. if there is excessive pa
I'm curious why the amount of RAM is relevant as all of our OS have virtual
memory so it is only the size of the heap and the amount of swap that
should be relevant for an Out Of Memory error, right? How big is your heap?
Amount of RAM should only affect speed (i.e. if there is excessive paging)
bu
You aren't the only one. The vector test suite also has these kind of
issues. In its case, it's hard for me to tell how big the code is, because
template haskell is being used to generate it. However, I don't think the
template haskell is what's using the additional performance, because the
test su
Building with https://downloads.haskell.org/~ghc/7.10.1/ghc-7.10.1-src.tar.xz
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768156.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
Thomas Miedema wrote:
>Maybe `split-objs` is not applied?
>
>* Stray `SplitObjs = NO` in your build.mk?
Tried adding SplitObjs = YES, didn't help
> * You're on an old OS X with XCode < 3.2?
Debian Jessie
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Binary-bloat-in-
I will. But I was curious whether this is only me or is anyone else seeing
similar behaviour. And
what about performance comparisson between 7.8.4 and 7.10.1? Do we have any
numbers?
Janek
Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał:
> Post a bug report! :)
>
> On Apr 2, 2015, at
Post a bug report! :)
On Apr 2, 2015, at 8:19 AM, Jan Stolarek wrote:
> An update frrom my second machine, this time with 4GB of RAM. Compiling Agda
> ran out of memory
> (again Agda.TypeChecking.Serialise module) and I had to kill the build. But
> once I restarted the
> build the module was
An update frrom my second machine, this time with 4GB of RAM. Compiling Agda
ran out of memory
(again Agda.TypeChecking.Serialise module) and I had to kill the build. But
once I restarted the
build the module was compiled succesfully in a matter of minutes and using
around 50% of memory.
This
Maybe `split-objs` is not applied?
* Stray `SplitObjs = NO` in your build.mk?
* You're on an old OS X with XCode < 3.2?
* Build system bug?
On Thu, Apr 2, 2015 at 11:19 AM, Jeremy wrote:
> Very strange. If I download Cabal from hackage and build it with 'cabal
> build' the bloat disappears.
>
>
Woops, never mind.
On Apr 2, 2015 7:53 AM, "Carter Schonwald"
wrote:
> Do you have profiling enabled locally?
> On Apr 2, 2015 5:19 AM, "Jeremy" wrote:
>
>> Very strange. If I download Cabal from hackage and build it with 'cabal
>> build' the bloat disappears.
>>
>> cabal build:
>>
>> 18M HS
Do you have profiling enabled locally?
On Apr 2, 2015 5:19 AM, "Jeremy" wrote:
> Very strange. If I download Cabal from hackage and build it with 'cabal
> build' the bloat disappears.
>
> cabal build:
>
> 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
> 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2
Very strange. If I download Cabal from hackage and build it with 'cabal
build' the bloat disappears.
cabal build:
18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a
/usr/local/lib/ghc-7.10.1:
23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
5
18 matches
Mail list logo
