Hi Ranjit, > I should have added that you should call them after compiling the > particular target (or with the environment obtained after compiling > from a particular target) did you do that?
I don't compile anything in my context, but I'm just reading the information of already compiled modules/packages. So if I'm using 'lookupRdrNameInModule' instead of 'tcRnLookupRdrName', than I'm getting the desired information, perhaps that's the difference between your and my use case. But now I'm seeing, that my previous profiling was a bit halfhearted and I missed the real hot spot. After adding several cost centres by hand, I'm seeing that getModuleInfo takes up the most time. Does anyone know why that's the case, why getModuleInfo is so costly and if there's an other way to get the exports of a module? Most allocations seem to be done by getModuleInfo, so getModuleInfo seems to create the data structures holding the complete module information. So there's presumably little hope to get this information faster, right? Greetings, Daniel _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
