In the beginning I had a code snippet, for example:
data Something = Something !Word32 !Word32 retrieveSomething :: Socket -> IO (Something) retrieveSomething sock = do ... function sock = do (Something xy) <- retrieveSomething sock let (a,b,c) = case x of 0 -> (foo,bar,baz) 1 -> (foo2,bar2,baz2) ... doIOwithParams abc
What I profiled with the -hy -hC"..." RTS option.
Looking at the heap profiles, I saw that using 3 tuples consumed too much memory, so I used the unboxed tuples extension (i.e. (# a,b,c #) ), which looked better suited to return multiple values .
I am more or less convinced that the use of the heap has been reduced since I tested it by making explicit calls to stuff before trying out the unpacked tuples, but by this I can no longer observe the different types of values allocated in the cost center.
To clarify the problem a bit more, I could see how many spatial values of the type Something (and something else) took a bunch after profiling the application without unpacked tuples. Now there is only one type on the heap graph, which I believe is associated with the mutable hash table calls that I make in the function call.
Is there any way to fix this?
Change Although it makes sense that the profile does not display unnecessary tuples, I am still confused by why their use hides everything else in the function call / cost center.
I tried profiling using explicit calls, rather than using unpacked tuples, for example:
case x of 0 -> doIOwithParams foo bar baz 1 -> doIOwithParams foo2 bar2 baz2
In addition to the fact that the overhead of 3 tuples is no longer visible, something and all the other types used in this function are also visible, which contradicts the case when I have unpacked tuples where I can only see Node (which may or may not be associated with the used hash line), which takes up space compared to other types.