Ah, ok. So I ran the code with 10 items,
5 items, and 25000 items and got total memory
in use of 28Mb, 15Mb, and 8Mb respectively. That
comes to 260-280 bytes per record which is still
an order of magnitude higher than the 20-30 bytes
per record we would expect.
On the other hand, I
On Tue, 25 Jan 2005, David Menendez wrote:
Does having 'zipped' at the top level mean that the program is keeping
the entire 100,000-element list in memory?
I don't know, but I tested with zipped at the top,
in the where, and it appears to make no
performance or memory difference.
Also, would pe
On 26 January 2005 16:42, S. Alexander Jacobson wrote:
> On Wed, 26 Jan 2005, Simon Marlow wrote:
>> When using the ordinary 2-generation collector, memory in use will
>> tend to be 2-3 times larger than the actual residency, because this
>> is a copying collector.
>
> Ok. Perhaps you want a diff
On Wed, 26 Jan 2005, Simon Marlow wrote:
When using the ordinary 2-generation collector, memory in use will tend
to be 2-3 times larger than the actual residency, because this is a
copying collector.
Ok. Perhaps you want a different name for
this item in the reports?
On the other hand, I found 10
S. Alexander Jacobson wrote:
zipped =zip [1..] [1..10]::[(Int,Int)]
untup f (x,y) = f x y
produce = foldr (untup Map.insert) Map.empty zipped
fm = length $ Map.keys produce
main = print $ fm
Has this profile:
example +RTS -p -K5M -RTS
total time =5.10 secs
On 26 January 2005 14:29, S. Alexander Jacobson wrote:
> Ah, ok. So I ran the code with 10 items,
> 5 items, and 25000 items and got total memory
> in use of 28Mb, 15Mb, and 8Mb respectively. That
> comes to 260-280 bytes per record which is still
> an order of magnitude higher than the
On 25 January 2005 23:27, S. Alexander Jacobson wrote:
> Oops. It pays to check your checking code before
> making posts like this.
>
> After actually running the correct test, I am
> still getting semi-ridiculous space behavior
> (6k/pair)!
>
> import qualified Map
> zipped =zip [1..]
S. Alexander Jacobson writes:
> After actually running the correct test, I am
> still getting semi-ridiculous space behavior
> (6k/pair)!
>
> import qualified Map
> zipped =zip [1..] [1..10]::[(Int,Int)]
> untup f (x,y) = f x y
> produce = foldr (untup Map.insert) Map.empty
Oops. It pays to check your checking code before
making posts like this.
After actually running the correct test, I am
still getting semi-ridiculous space behavior
(6k/pair)!
import qualified Map
zipped =zip [1..] [1..10]::[(Int,Int)]
untup f (x,y) = f x y
produce = foldr (unt
> Just did a search after my last post and learned
> that FiniteMap is bad. Discoverd that Data.Map is
> the intended replacement. Downloaded it and
> modified it to work with 6.2. Blazingly fast!
>
> Yay.
Hi, just curious,
How much trouble was getting it to work with ghc 6.2 and adapting you
I didn't find any such information. I just
decided to look at the FiniteMap source code in
CVS and discovered in the comments that it was
deprecated in favor of Data.Map.
So I downloaded the new Data.Map and Data.Set and
ran the code I posted before. I executed
basically instantly and used
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> Just did a search after my last post and learned that FiniteMap is
> bad. Discoverd that Data.Map is the intended replacement. Downloaded
> it and modified it to work with 6.2. Blazingly fast!
Oh? I was aware that Data.Map was supposed to
12 matches
Mail list logo
