summaryrefslogtreecommitdiff
path: root/configure.ac
diff options
context:
space:
mode:
authorDaniel Drake <dsd@laptop.org>2013-07-09 13:03:36 -0600
committerSimon Feltman <sfeltman@src.gnome.org>2013-07-10 11:24:33 -0700
commita93755ddba9a1761b627583d7b9be63783c2c063 (patch)
tree0dae36903e1a453937f8dee61d330f5e30f9202d /configure.ac
parent7aca95781fc76f3e820e63325ccc07d128a60075 (diff)
downloadpygobject-a93755ddba9a176.tar.gz
Speed up MRO calculationa93755ddba9a176
Optimize gi.type.mro() with the following observations and tricks: 1. Python prepares all the base classes before trying to calculate the MRO of the current one (it first needs to populate __bases__, for example). So we can assume that the base class MRO is already available in __mro__ and this will have been previously calculated (by us, in the case of gi classes). This avoids repeating a lot of MRO-calculating work, and also avoids (re)calculating MROs for inheritance chains that don't have any gi classes in them anyway. 2. With that simplification in place, we can avoid recursion, which is not all that great in Python... 3. ...except in the uncommon case of a Python2 old-style classes, where __mro__ is not available. There doesn't seem to be any existing function to calculate or read MRO of old-style python classes, so just keep doing as before: calculate the C3 MRO of the old-style class via recursion. That behaviour is not really correct, and the recursion is not desirable, so we print a warning here. This makes the "hello world" Sugar app start up approximately 0.5 seconds faster on XO-1.5. https://bugzilla.gnome.org/show_bug.cgi?id=703829
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions