On Sat, Feb 16, 2013 at 4:30 PM, Stefan Fuhrmann
<stefan.fuhrmann_at_wandisco.com> wrote:
> On Sat, Feb 16, 2013 at 5:47 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>>
>> On Sat, Feb 16, 2013 at 4:52 AM, Stefan Fuhrmann
>> <stefan.fuhrmann_at_wandisco.com> wrote:
>> > Hey all,
>> >
>> > Just to give you an update on what is going on that branch,
>> > here a few facts and numbers. Bottom line is that there is
>> > still a lot to do but the basic assumptions proved correct and
>> > significant benefits can already be demonstrated.
>> >
>> > * about 20% of the coding is done so far
>> > * some core features implemented:
>> > logical addressing, reorg upon pack, block read
>>
>> What do you mean by pack here? Is it svnadmin pack?
>
>
> svnadmin pack
>
>>
>> Is that in any way an essential part of the performance boost?
>
>
> Yes. It will places items (noderevs, representations, change lists)
> next to each other when they will likely be requested shortly
> after one another. For instance, try to concatenate all elements
> of a deltification chain.
>
>>
>> Or are your format7 repositories always packed?
>
>
> They are not. Unpacked revisions will see a performance hit from
> reading the two extra index files per revision and a boost from
> block-read which will often fetch the whole revision with a single
> I/O operation.
So is the main difference between format 6 and 7 how the data is
organized when they are packed?
> Quite a number of reasons:
>
> * easy setup
> * minimal overhead (I want to get as close to measuring pure
> FS layer performance as possible)
> * easy to debug and profile
I get that for development purposes, but I would personally like to
see that the caching etc. is yielding benefits when HTTP is used.
> '--enable-optimize' is new in 1.8. It should probably be documented
> somewhere but I'm not sure how safe it is to *recommend* it to
> packagers. The optimizations are quite aggressive and might break
> unclean code.
>
> I used it in conjunction with '-march=native' to minimize CPU time
> vs. I/O time. It saved 3 .. 5% of CPU cycles in my tests.
OK.
BTW, how are you managing your branch? I tried merging it back to
trunk to get an idea on the diff and there were a lot of text and tree
conflicts. I thought I had seen you doing synch merges from trunk in
the past so I assumed it would merge back.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-02-18 17:55:00 CET