comp.lang.haskell Google Group

Re: performance question

2010-03-08T09:30:33Z

thanks for the comments. just an update what i have tried and not
worked:
- put more `seq` wherever i can,
- create map for each file separately and merge them at the end.
but most surprisingly the small change, what made it:
- build the reverse graph (instead of which includes which, now i
collect which were included from where.)

Re: pimp my code

2010-03-06T05:46:36Z

You're welcome. Getting used to Haskell takes some time, and if you
need more details, feel free to ask.
- Dirk

Re: pimp my code

2010-03-05T20:25:13Z

On Mar 4, 5:27 am, Dirk Thierbach <dthierb...@usenet.arcornews.d e>
wrote:
thanks for the tips.
peace
stm

Re: ghc warning

2010-03-04T14:48:27Z

Now that I see it, it looks obvious ;-)
Thanks,
Laurent

Re: ghc warning

2010-03-04T14:30:12Z

It's wondering which integral type to use after rounding but before
converting back to Double. For instance,
rint :: Int -> Double -> Double
rint d x = fromIntegral (round (x * 10^d) :: Integer) / 10^d
Mark

ghc warning

2010-03-04T14:11:38Z

When I compile
rint :: Int -> Double -> Double
rint d x = fromIntegral (round (x * 10^d)) / 10^d
GHC reports
main.hs:442:25:
Warning: Defaulting the following constraint(s) to type `Integer'
`Integral b' arising from a use of `round' at main.hs:
442:25-40
In the first argument of `fromIntegral', namely

Re: pimp my code

2010-03-04T13:27:45Z

There's a number of inefficiencies in your code. I could go through the
code in detail, but that would probably end with a complete rewrite :-),
so I'll just do a summary (unless you still get stuck):
* Haskell has to read a sequence of bytes, convert them into a list of
Char, then another time into a list of Int, and then you process them.

pimp my code

2010-03-04T06:27:10Z

hi all
here is a little module for parsing midi files. it seems to work, but
it's much slower than its python counterpart. maybe somebody could
look through it and see if i'm making any obvious mistakes?
peace
stm
{----------------------------- ------------------------------ ------------------------------ ---

Re: performance question

2010-02-17T20:10:35Z

LAca wrote:
If you do random access, using arrays might improve performance
dramatically. Singly linked lists are really slow.
Hans

Re: performance question

2010-02-17T17:58:24Z

My first instinct would be to look hard at the map operations you have:
I've had some laziness surprises from those in the past. I'm guessing
that the Map.insertWith only deals with small values anyway? Are you
sure that the foldWithKey is as strict as you hope? If anyone else
suggests anything, they're probably more likely to be correct than I am,

performance question

2010-02-17T17:34:51Z

hi All,
I'm trying to create a simple application, which parses CPP output
files and creates a graphviz dot file. You can find the source here:
[link]
I'm using test files ~25GB as input, the allocation is ~1.5GB. I tried
to profile the application, but found not too much. The (:) allocates

Re: enumerations

2010-02-12T09:54:39Z

On Feb 11, 5:30 pm, Dirk Thierbach <dthierb...@usenet.arcornews.d e>
wrote:
Thanks Dirk, it has helped!

Re: enumerations

2010-02-11T16:30:55Z

You have to add a pragma:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}

newtype Color = Color Int deriving (Eq,Ord,Enum)

(red:blue:black:_) = [Color 1 ..]
*Main> :t red
red :: Color
But I doubt that this will increase the performance a lot. If you do
a bit of profiling, you'll probably find other places to optimize, with

Re: enumerations

2010-02-11T16:15:20Z

The examples there seem to work fine. But first you should consider
whether you need such a hacky optimization. Perhaps serialization is
what you need.
Greets
Ertugrul

enumerations

2010-02-11T14:19:54Z

hello All,
i tried to tune up my little application, and have found this page:
[link]
but the example does not even compile for me. anyone could give me a
hint how to write enumeration shortly?
thanks,
Laszlo