Using a simple, hysteresis based approach… currently in this first
version the optimizer recursively moves modules out of a thread until a
certain timing target is reached; the "modules moved out" just mentioned
are then partitioned into new threads according to their latest time profile.
Very simple, but very effective.
Todo: Implement merging threads with (again) good behaving workloads.
I thought: Well, isn't it a bit redundant if I go ahead and say in my
config "import this-n-that and temp and load and alsa" while later
just giving register() the modules.
So register() (/ClassFinder as the backend) now support just naming a
module as the first parameter. That module is then imported and
searched for a class as usual.
Just for reference the synopsis of Status.register():
register(mod.SomeChecker())
register(mod, setting1=..., setting2=...)
register(mod, {"setting1:":, "setting2":...})
register("mod", setting=1..., setting2=...)
register("mod", {"setting1:":, "setting2":...})
Fun fact: Actually register() doesn't care for it's arguments.
They're passed straight into ClassFinder.instanciate_class_from_module
(something I should definitely rename), which checks if it's first
parameter is one of:
-Python module
=> It calls ClassFinder.get_class with the same parameters
=> get_class will search the module using ClassFinder.search_module
and return a matching class if and only if there is a single matching
class in the module
-string
=> It calls ClassFinder.get_module to import the module and calls itself
on the result
-something else
=> It returns that something
The actual variation in passing the settings (keyword arguments vs. dict)
is handled in SettingsBase.