[Merge] Slow socket

[Carl Friedrich Bolz]

I've updated the slow-socket patch once again, I hope it is ok now.

John Arbash Meinel wrote:
>> The intention was to have at least _some_ lines which get removed
>> when the file is changed again, and not just more and more added lines.
>
> Okay. I think it is a little odd, but probably fine for manually
> generated changes.

I guess the only way to get some realism with this is to actually use a
tree for an existing project. How about the following (unrelated to this
merge, just an idea): Put three test-trees (small, medium, big) of
existing projects into a zip file somewhere on a website and write
benchmarks that look for these trees (for example in
bzrlib/benchmarks/example_trees) and run with these trees. If the trees
are not present, the benchmarks would be skipped.

>> Moved this. I was not so sure whether it is of general use, I guess in
>> the end more and more benchmarks will use the same convenience functions
>> to create trees with certain properties.
>>
>> In addition I think the tree creation function should be updated to use
>> John's new caching mechanism. Should I update the patch again or do it
>> with an extra merge? These particular trees are not very big, so maybe
>> it is ok not cache.
>
> 100x100 is probably pretty small how long does it take for you to
generate?
>
> I think having 'create_with_commits' be cached would be reasonable. But
> obviously commit_some_revisions should not.
>
> I can see us wanting to scale up to 1k x 1k, or even 10k x 10k, which we
> really would want to cache.
>
> I don't think it is a requirement to get this merged, though.
> (Especially since you aren't caching them in some other way, so there
> isn't a conflict.)

I can write a separate merge request for this (after my vacation,
though).

>
> I'm curious about the accuracy of this. Did you ever try using 'tc' and
> comparing the results? Were they somewhat related?
>

Yes, I did, and yes, they were somewhat related. But to find out whether
this is really a good approach a somewhat more extensive test would be
needed, to check in various parameters whether the result is realistic.

[snip]

> I think 'directory_name' is a little bit long... I use 'root' or 'dest'
> in other locations. Some might not like my variable names either,
> though. The only strict requirement is that they be meaningful.

directory_name is used in existing tree-building functions, so I kept
that name.

[snip]

Cheers,

Carl Friedrich Bolz