[PATCH 3 of 3 V2] chgserver: add a config option to preload repo

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Mar 16 21:17:56 EDT 2016



On 03/16/2016 06:13 PM, Yuya Nishihara wrote:
> On Wed, 16 Mar 2016 16:13:01 -0700, Pierre-Yves David wrote:
>> On 03/16/2016 03:59 PM, Jun Wu wrote:
>>> On 03/16/2016 08:12 PM, Pierre-Yves David wrote:
>>>> Isn't it a bit early to play with that ? I would advocate that we get
>>>> something running (pass all tests, including 3rd party of interrest to
>>>> you)
>>>> then introduce these option with some timing data.
>>>
>>> The patch is about a new direction. I do want feedback on this topic early.
>>> It won't change the current chg behavior by default.
>>
>> Then it should live the 'experimental' section until we get a better
>> idea of if this is useful or not.
>
> Oops, I said "chgserver" section would be okay as the extension is experimental.

ha, interresting point. You are probably right here. But the option 
still have a flavor of "some random flag that won't survive once we know 
what is the right way." so it made me thing of experimental.

How much of chgserver were already existing in its own repository. 
Because in that case, this is "experimental" but not so much as we 
probably don't want to break older user for nothing?

(on "where" this option live, I'll let yuya decide)

>>>> Because right now, we suspect this would help but we seems to be lacking
>>>> performance number to back there usefulness.
>>>
>>> I have the number for a large fb repo. "preloadrepo = True" saves 40ms.
>
> But the cached repo would be useless once the repository is modified, because
> the server forks per connection, right?
>
> I don't think this caching strategy would work well.
>
>
>> +def _reporoot(repo):
>> +    if not repo:
>> +        return None
>> +    return os.path.realpath(getattr(repo, 'root', None))
>
> Nit: os.path.realpath(None) raises exception

If this raises exception, I would raise your concern a bit above "nit" 
then ;-)

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list