On 14/04/2011, at 6:24 PM, Simon Marlow wrote:
I made some changes to the storage manager in the runtime today, and
fixed the slop problem with your program. Here it is after the
changes:
14,928,031,040 bytes allocated in the heap
313,542,200 bytes copied during GC
18,044,096
On 19/04/2011 14:41, Tim Docker wrote:
On 14/04/2011, at 6:24 PM, Simon Marlow wrote:
I made some changes to the storage manager in the runtime today, and
fixed the slop problem with your program. Here it is after the changes:
14,928,031,040 bytes allocated in the heap
313,542,200 bytes
On 23/03/2011 02:32, Tim Docker wrote:
On Mon, Mar 21, 2011 at 9:59 AM, I wrote:
My question on the ghc heap profiler on stack overflow:
http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-output-of-the-ghc-heap-profiler
remains unanswered :-( Perhaps that's not the best
On 22/03/2011 16:47, Brandon Moore wrote:
On Tue, March 22, 2011 21:00:29 Tim Dockert...@dockerz.net wrote:
I'm a bit shocked at the amount of wasted memory here. The sample data file
has ~61k key/value pair. Hence ~122k ByteStrings - as you point out
many of these are very small (1500 of
On Wednesday 23 March 2011 03:32:16, Tim Docker wrote:
On Mon, Mar 21, 2011 at 9:59 AM, I wrote:
My question on the ghc heap profiler on stack overflow:
http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-
output-of-the-ghc-heap-profiler
remains unanswered :-(
On 22/03/11 05:33, Daniel Fischer wrote:
On Wednesday 23 March 2011 03:32:16, Tim Docker wrote:
Is the slop number above likely to be a significant contribution to net
memory usage?
Yes, absolutely.
Are there any obvious reasons why the code below could be
generating so much?
I suspect
Hi Tim,
Sorry I can't tell you more about slop (I know less than you at this point),
but I do see the problem. You're reading each line from a Handle as a
String (bad), then creating ByteStrings from that string with BS.pack
(really bad). You want to read a ByteString (or Data.Text, or other
On Wed, Mar 23, 2011 at 9:32 AM, Tim Docker t...@dockerz.net wrote:
Productivity 78.2% of total user, 76.5% of total elapsed
As a rule of thumb GC time should be less than 10%.
This seems strange. The maximum residency of 12MB sounds about correct for
my data. But what's with the 59MB of
Minor update, here's how I would handle this problem (using uu-parsinglib
and the latest ListLike, mostly untested):
import Data.ListLike (fromString, CharString (..))
import Text.ParserCombinators.UU
import Text.ParserCombinators.UU.BasicInstances
import Text.ParserCombinators.UU.Utils
--
On Tue, March 22, 2011 21:00:29 Tim Docker t...@dockerz.net wrote:
I'm a bit shocked at the amount of wasted memory here. The sample data file
has ~61k key/value pair. Hence ~122k ByteStrings - as you point out
many of these are very small (1500 of them are empty). Assuming it's the
On 22/03/11 10:47, Brandon Moore wrote:
It sounds like the space is allocated but unused pages. Unless you have messed
with some kernel memory manager settings, unused virtual pages consume no
physical RAM.
You could confirm this by using ps to check how much RSS is actually used,
compared to
11 matches
Mail list logo
