dagit: > On Wed, Oct 29, 2008 at 7:52 AM, David Roundy <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 29, 2008 at 01:00:08PM +0000, Eric Kow wrote: > >> As I mentioned earlier, this is the promised Salvo 8 (the big one), > >> which I have verified to pass tests on both GHC 6.6 and 6.8. > >> > >> If it helps, here is my contribution to the review. > >> > >> I think once we get over this hump, the merging the rest of sprint > >> patches in (or not) is easy > >> > >> Also, if there are any changes to be made, I think we should make them > >> *on top* of this bundle because amend-recording is simply not going to > >> be practical (I don't meant to belabour the point, it's just that > >> amending is a bit ingrained in our culture, so people get a bit nervous > >> when there is a large amount of work that wants to get in) > > > > I don't think I'll have time to review this bundle today, but had a > > question I'd like to ask even before I review it. I presume this has > > been benchmarked against the pre-salvo-8 version. How does it affect > > timings? Not that timings are everything, but it'd be nice to see if > > it speeds things up or (although it seems unlikely) slows things > > down, and if so, by how much. > > I want to see benchmarks too, but I thought I would justify why we > expect this to be no slower than the previous code...Everything below > is stuff that we discussed during the Sprint. > > For every thing that Don rewrote (like removing the C code) he checked > that the code generated by GHC after the change was at least as good > as the code generated before it. He said it looked like the generated > code was either same or better in each case. > > I recall him commenting on at least one case where some indirection > had been removed which could speed it up if the function gets called > often. Don also moved around some of the pack/unpack calls to either > remove them totally or call them less often. This should be an > improvement because there will be less copying and less garbage. > > Finally, the last thing he did was to use more of the ByteString api > which should also be a win because he and others have worked hard to > make everything in ByteString faster than it was in FastPackedStrings. > > Hopefully someone will make those benchmarks. That would be cool to > quantify the improvement. It would make a good marketing blog post :)
Yes, I'd like to see benchmarks. I expect we removed some constant factors. -- Don _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
