Heidi Eckhart wrote:
> optimization (correctly) if we decide it's needed.
Now, that you both pick up the filter_results() function, this is a
good time to enter this discussion. I agree that the filter_results()
function is handy and takes away a lot of checking and distinguishing
from the provider. For tiny numbers of returned instances and fast
systems, this will not cause any problems. But we should keep in mind,
that the providers should also scale for a large number of virtual
machines. As Dan already mentioned - this approach will become an
performance issue later. On the other hand its more the responsibility
of the provider - especially for our ones, that handle a lot of
subclasses at one time - to filter the returned instances, as the
responsibility of the generic association logic. So I want to follow
Dan's opinion and keep it for now. But we should add this to our ToDo
list and fix as time allows. I suppose this will mean to reorganize
the providers a bit and I do not expect a huge effort.
I agree - I was concerned about performance when I wrote the
filter_results() code. =) It would probably be a good idea to test all
of the providers for performance at some point. Since the enum
extrinsic functions don't return until all the instances are generate,
you could potentially run into some performance issues there as well.
--
Kaitlin Rupert
IBM Linux Technology Center
karupert(a)us.ibm.com