# how much can %alloc in profiling be trusted

Hal Daume t-hald@microsoft.com
Wed, 9 Jul 2003 15:17:05 -0700

```In my program, I get the following time/allocation information for a
call to my cosine function:

individual      inherited
COST CENTRE   no. entries  %time  %alloc  %time  %alloc
cosine               2721  43.1   74.3    43.1   74.3

this is a shocking amount of allocation, considering the definition of
the function:

cosine :: Vector -> Vector -> Double
cosine v1 v2 =3D=20
case dot v1 v2 0 of
n | n <=3D 0    -> 0
| otherwise -> n / (size v1 * size v2)
where=20
dot [] _  n =3D n
dot _  [] n =3D n
dot ((x,xv):xs) ((y,yv):ys) n =3D
case x `compare` y of
EQ -> dot xs ys \$! (xv * yv + n)
LT -> dot xs ((y,yv):ys) n
GT -> dot ((x,xv):xs) ys n
--    size =3D sqrt . sum . map (square . snd)
size l =3D sqrt \$! size' l 0
size' [] n =3D n
size' ((_,x):xs) n =3D size' xs \$! n + x*x

where Vector =3D [(Int,Double)] is a sparse vector representation.  This
was even higher (moderately) until I switched from the old to the new
definition of size listed there.

You can't blame this on the fact that the two vectors are being passed
lazily either: they're being read strictly from a file and even seq'd
before being put into the list.  Specifically, we have (v0 is passed in
to the function from top-level):

... do
return (cosine v0 v, w)

b <- FastIO.isEOF h
c <- FastIO.fscanfChar h
if c /=3D ' '=20
then return []=20
else do
b <- FastIO.isEOF h
i <- FastIO.fscanfInt h
FastIO.fscanfChar h
v <- FastIO.fscanfFloat h
return ((force (force i,force \$ floatToDouble v)) : rest)
where force x =3D x `seq` x

as far as i can tell, all the list allocation should be happening here.
(the forces were not there in the beginning -- I added them later but it
changed nothing.)

- Hal

--
Hal Daume III                                   | hdaume@isi.edu
"Arrest this man, he talks in maths."           | www.isi.edu/~hdaume

```