GNOME Bugzilla – Bug 640650
resolve class members lazily on first usage
Last modified: 2018-01-10 20:02:37 UTC
inside __getattr__ because some classes can be very big and only a very small part of the API will be used in typical applications. This will save startup time and memory at the expense of a little more overhead on the first invocation of a method.
Created attachment 252949 [details] [review] work in progress I started to look at this, specifically making method lookup lazy as a first step. Here is a messy patch so far. It is a bit more complicated than I anticipated. For example, if you don't find the method on your own class, you do need to check parent classes to find it. super() can no longer be used as it does not trigger __getattr__ to happen, http://stackoverflow.com/questions/12047847/super-object-not-calling-getattr I haven't quite got my head around the whole bound/unbound method thing yet, and how to deal with that in __getattr__. Right now I am at the point where this patch causes random crashes, easily exposed by the test suite. Looking with valgrind, bad memory accesses are happening. However that is true even with current master.
Review of attachment 252949 [details] [review]: I think this is a good first step. The super() problem is probably a deal breaker but it may be possible to get around this because we control our own versions of bound/unbound methods (GICallableInfo). This might also be related to bug 710646.
An alternate approach for improving the performance this ticket aims to help would be to move all overrides with deprecated intializers behind a logic statement. The statement could check for enablement of skipping deprecated initalizers as mentioned in bug 723736.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/10.