Startup time is regressing

FUJIWARA Katsunori fujiwara at ascade.co.jp
Tue Nov 9 09:04:49 CST 2010


Hi, 

At Tue, 09 Nov 2010 09:45:58 +0100,
Martin Geisler wrote:
> 
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Mon, 2010-11-08 at 09:52 +0100, Dirkjan Ochtman wrote:
> >> On Mon, Nov 8, 2010 at 00:44, Matt Mackall <mpm at selenic.com> wrote:
> >> > That's the time it takes to run 'hg version -q'. That's 28.7% slower,
> >> > mostly since 1.5. Most of the big hit in 1.6 appears to come from:
> >> >
> >> > changeset:   11297:d320e70442a5
> >> > user:        FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> >> > date:        Sun Jun 06 17:20:10 2010 +0900
> >> > summary:     replace Python standard textwrap by MBCS sensitive one for
> >> > i18n text

Ouch ! My patch has caused regression, sorry !

> >> Sounds like maybe we should make that optional.
> >
> > My locale is C, so we shouldn't actually be getting anywhere near this
> > code.
> 
> We do not call the util.wrap function for 'hg version', so the
> performance hit is for defining the class. I guess the problem is that a
> subclass of textwrap.TextWrapper force-loads the textwrap module.

I confirmed that defining the sub class of textwrap.TextWrapper causes
regression, as Martin says.

> I just looked at the textwrap module, and the TextWrapper class is
> fairly short -- lots of comments but little code. I suggest we borrow
> the code, fix it to handle wide characters and take out the unneeded
> parts such as handling double-space after periods. Then put the whole
> thing in i18n.

I also confirmed that both ways shown below can prevent startup time
from regressing.

    1. move sub class definition from util.py to other file

    2. define sub class on-demand like:

        ====================
        MBTextWrapper = None

        def wrap(...)

            global MBTextWrapper
            if not MBTextWrapper:
                class MBTextWrapper(textwrap.TextWrapper):
                      ....

            wrapper = MBTextWrapper()

        ====================

I think (1) is better for its simplicity.

--------------------
[FUJIWARA Katsunori]      fujiwara at ascade.co.jp(foozy at lares.dti.ne.jp)



More information about the Mercurial-devel mailing list