Folks, after using ghc --make happily in a project for a while I am switching to using Makefiles since I have a number of Main programs in the same directory that share a lot of modules. Now, since ghc -M does such a great job at gobbling up the dependencies, I wonder if it was not possible to extend its functionality a little bit so that it also determines the .o files that are required to link a Main program. I could imagine something like an -optdep-Main and then the program name. -Peter
Hi Peter,
Now, since ghc -M does such a great job at gobbling up the dependencies, I wonder if it was not possible to extend its functionality a little bit so that it also determines the .o files that are required to link a Main program. I could imagine something like an -optdep-Main and then the program name.
Could come in handy sometimes, perhaps, but maybe there are other ways? If it is the size of the resulting executables that prevents you from linking each main.o file with all the other .o files (except the main ones), couldn't you just put all the non-main .o files into an archive and then let the linker figure out what to link against what for you? Make has pretty much all rules for building archives in a good way built in, so this is easy to do. If it's mainly a matter of avoiding clashes between the different Main modules, it should, with a little bit of care, not be too hard to structure the makefile to deal with that. Regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
Folks, here is the piece of code that takes most of the time in a program I have: f6 = {-# SCC "f6" #-}\gumd -> let fileName = usermetadir ++ gumd in catch (do h <- {-# SCC "f6.1" #-} openFile fileName ReadMode str <- {-# SCC "f6.2" #-} hGetLine h _ <- {-# SCC "f6.2a" #-} hClose h return $ {-# SCC "f6.3" #-} words str) (const $ return []) Profiling yields this output: individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc f6 MailStore 346 577 0.0 3.5 87.5 85.1 f6.3 MailStore 351 0 0.0 9.9 0.0 9.9 f6.2a MailStore 350 0 0.0 0.7 0.0 0.7 f6.2 MailStore 349 0 0.0 7.5 0.0 7.5 f6.1 MailStore 347 0 87.5 63.5 87.5 63.5 If I read this correctly, openFile performs 63.5% of all allocations and takes 87.5% of the runtime. Now I'm wondering about ways to cut that down: 1. How can I avoid the allocations inside of openFile? 2. Would it help to call f6 in different threads? That is, does a thread yield when it calls an IO function? Any help appreciated. -Peter
participants (2)
-
nilsson＠cs.yale.edu -
Peter Thiemann