muzidudu / grit-i18n

Automatically exported from code.google.com/p/grit-i18n
0 stars 0 forks source link

Improve grit startup time #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Nico claims that:
"grit is very slow because it has all these module-scope 're.compile' calls 
which
get executed at module load time. grit imports all its modules but uses only a
few of these regexen on every run depending on various flags. So as a result
grit has slow startup because of its 'global' re.compile statements."

git grep counts 57 lines with re.compile (outside of unittest.py files).  If 
someone has time to profile, that would be great.

Original issue reported on code.google.com by tony@chromium.org on 21 Feb 2012 at 9:16

GoogleCodeExporter commented 9 years ago
I did the profiling back when I tried to make gyp faster. 
http://codereview.chromium.org/7035004/ saved 7s in chromium; all it did was 
make gyp not pay repeated grit startup.

Original comment by thakis@chromium.org on 21 Feb 2012 at 9:22

GoogleCodeExporter commented 9 years ago
I see, your earlier change made it so we don't invoke grit as often at gyp 
time.  I think we still invoke grit multiple times during the build.  We could 
maybe save some time there by lazy compiling the regexen. 

Original comment by tony@chromium.org on 21 Feb 2012 at 9:25

GoogleCodeExporter commented 9 years ago
I timed the "do nothing".  For a loop of 100, each invocation of [ grit ] or [ 
grit build ] on my HP Z600 takes a little less than 0.08s of wall-clock time.  
By switching all re.compile statements to a no-op lazyre.compile statement, 
this drops to a little over 0.06s per invocation.  So it looks like it's not 
just the regular expression compilation, more likely the Python parsing in 
general.  I'll see if the code can be refactored to not import unnecessary 
modules all the time.

Original comment by joi@chromium.org on 21 Feb 2012 at 10:35

GoogleCodeExporter commented 9 years ago
r14:

Improve GRIT's start-up time since Chrome invokes it so many times.

This is accomplished by (a) not always importing all of the GRIT code
in grit_runner.py, and (b) switching all regexes compiled at parse
time to use a new lazy_re module.

For 100 iterations in a shell on an HP Z600 workstation, this has the
following effects per iteration:
- [ grit build ] (without valid input) drops from ~0.08s to ~0.03s.
- [ grit ] (note this still must import everything) drops from ~0.08s
  to ~0.05s.
- [ grit_info ] (without valid input) drops from ~0.08s to ~0.05s.

BUG=http://code.google.com/p/grit-i18n/issues/detail?id=2
Review URL: https://chromiumcodereview.appspot.com/9372084

Original comment by joi@chromium.org on 22 Feb 2012 at 1:25

GoogleCodeExporter commented 9 years ago
r15:

Use getattr() to support Python 2.6 and older.

This approach is more robust, and works regardless of whether the RegexObject is
a new-style object (with __getattribute__) or not.

BUG=http://code.google.com/p/grit-i18n/issues/detail?id=2
Review URL: https://chromiumcodereview.appspot.com/9428029

Original comment by joi@chromium.org on 22 Feb 2012 at 1:37

GoogleCodeExporter commented 9 years ago
I believe the reported problem (lots of possibly unnecessary re.compile at 
startup time) was fixed by r14 and r15.

Original comment by joi@chromium.org on 28 Jun 2013 at 10:38