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
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.
Please ignore the prior message.
-Alex-
__
13 matches
Mail list logo
