Greg Steuck writes:
> Hi James,
>
> Thanks for gathering the data and analyzing it!
>
> I do not believe that speed of git-annex build should be a blocker to
> its inclusion into the tree. I'm just waiting for somebody to OK it
> before committing. Though maybe it's best to do that after the ghc 8.10
> upgrade, not sure?
Builds fine for me! ("61m47.59s real 36m53.69s user 14m31.75s
system" on my AMD Ryzen 9 3900X 12-Core Processor!)
OK abieber@
>
> James Cook <falsif...@falsifian.org> writes:
>
>> I agree with Greg's comment in the other thread that the ideal
>> solutions would be speeding up ghc or something like ccache. But I
>> still wonder if there's a quick-and-dirty way to get a modest speedup
>> without too much maintenance cost.
>
> For such a cache port to be of consequence it needs to contain a
> significant intersection of the dependencies of a non-trivial number of
> Haskell binary ports. As things stand, we have less than 10 ports. Only
> xmobar (+ git-annex and maybe pandoc in the future) would be big enough
> to bother with optimizing.
We should decide on a name for a file to store the MOD{CABAL,GO,CARGO}
dependency lists! These Makefiles are gonna be yuge!
>
>> What about adding a single port with a "collection" of commonly used
>> Hackage libraries? print/texlive does this with latex packages. If we
>> added a port with the few hundred most-used hackage packages, and other
>> Haskell packages could start with that, I'm guessing that would cut
>> down the total build time a lot, at the cost of having one big slow
>> port.
>>
>> If there's any interest I could probably find some time to try
>> implementing it. I don't know how hard it would be.
>
> I propose we don't solve the problem until it's big enough to warrant
> our attention. I know I'm bad at predicting how things will develop a
> year from now. This is why I don't want to speculatively build more
> complexity.
>
> Thanks
> Greg
