Optimising and re-optimising (Deja-vu for PySNMP hacking...)


Spent the whole day staring and poking at PySNMP. I think I see a way to speed the system up to something reasonable...

The basic problem is that any given final class, be it a simple integer holder or a full SNMP get message, is composed of about 20 mix-in and base classes, all of which are coded to be very generic (since they are mixed into just about every final class). The result is that every operation is running through about 20x the code required to implement just the particular case of that final class (that's an exageration, it's probably 10x).

Most of the decisions coded into the mix-in classes are actually dependent on class features, not instance features. That means that every single instance is wasting time figuring out which type of class it is for just about every operation. That kills performance.

For those of you following along, yes, it sounds like a problem crying out for a metaclass/metaprogramming solution, basically a specialising metaclass that takes a given final class and, instead of using the generic functions mixes in exactly those functions/methods required just for the final class.

Also ran into a weird situation where some fairly significant speedups I contributed a long while ago (and which were reported checked in) don't appear in the latest version. Don't know what's going on there. I'd guess we've got at least 10% speedup waiting just on that fix. I likely added another 1 or 2% speedup with fixes today (beyond that 10%). The goal, however, is a 75% speedup, so I've got a way to run yet.

Comments

Comments are closed.

Pingbacks

Pingbacks are closed.