On Mon, Sep 6, 2010 at 1:55 PM, Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de> wrote: > Hyrum K. Wright wrote: >> >> As I recall, Stefan recently declared the performance branch "done". >> > > Correct. I've just been polishing parts of it over the last > two weeks or so. >> >> It's encouraging to see a few intrepid users and devs looking at the >> branch and providing feedback. >> >> Through IRC and other conversations, I've gotten the feeling that some >> of the changes made on the branch might be a bit too wide-spread to >> warrant whole-sale inclusion in 1.7, but several people have expressed >> interested in cherry picking at least some bits back to trunk. I've >> not yet done a comprehensive review of the changes on the branch, and >> would appreciate any suggestions folks may have of low-hanging, >> independent useful bits. >> >> For starters, I would consider: >> * the new svn_io_file_read_full2() API >> * the new svn_io_file_putc() API >> * the new svn_stringbuf_appendbyte() API >> > > These are certainly good starters. Basically, all from io.c > should be easy to review and adopt in trunk. > > Somewhat higher hanging but still within reach IMHO, > is the svn_stream_readline() implementation plus the > required stream API extensions. The complexity is very > low but the performance impact is significant.
Good to know, those are the types of changes I'm looking for (initially). >> Note that I don't include the caching work, since I think it might be >> much more far-reaching, and probably needs more review before going >> into trunk. >> > > If I was to pick a single change that I would want to > see in 1.7, it is the membuffer cache being used as > full-text cache. It does not require any of the serialization > stuff, fs_fs.c or dag.c changes. And it is the single most > beneficial change wrt. to server performance. > >> The branch should also probably have a catch-up merge to prevent it >> from diverging too far. I'm happy to do so, as well as fix up any >> style nits which may exist on the branch. I'll do some digging to >> determine the various revision ranges to make the above suggestions >> merge to trunk, and post back. >> > > Please do ... it spares me the pain to do it myself ;) No problem. But please do look over my shoulder to ensure I don't botch the conflict resolutions too badly. :) -Hyrum