ZCatalog searches return "pluggable brain" instances rather than the catalogued object. You've got quick access to the catalogued meta_data, but if you want more then you've got to "wake up" the actual object - and there's a significant performance hit for doing so. Consider the following pared-down scenario: You set up a beautiful ZClass called Point. Point has two float properties, x and y. Point has a method "distance_to(test_point)" which returns the cartesian distance from itself to another Point instance (test_point). Now you catalog all your Point instances and conduct a search which returns a list of pluggable brains. You want to quickly find the distance from a given test point to each of the points returned by the search: 1) You wake up each object and call "distance_to(test_point)" for each. Clean but performance hit for waking up. 2) You add x and y as meta_data, rewrite the method distance_to(test_point) as distance_to(x,y). Now you no longer have to wake up each point as the x and y are quickly available in the pluggable brain. It's quicker but less object-oriented. Starts to look a little like old C code - distance_to(x1,y1,x2,y2). Further, it becomes a real mess when your "distance_to" calculation uses many properties in addition to x and y. Is there an alternative that I'm missing? Ideally you'd like to have object instances as meta_data in the catalog. Comments? Cheers, Darran. --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/
dee900@anusf.anu.edu.au writes:
.... 1) You wake up each object and call "distance_to(test_point)" for each. Clean but performance hit for waking up.
2) You add x and y as meta_data, rewrite the method distance_to(test_point) as distance_to(x,y). Now you no longer have to wake up each point as the x and y are quickly available in the pluggable brain. It's quicker but less object-oriented. Starts to look a little like old C code - distance_to(x1,y1,x2,y2). Further, it becomes a real mess when your "distance_to" calculation uses many properties in addition to x and y. Make a little test and compare the two approaches.
I would not expect that the performance penalty of method 1 is that great when the objects woken up are relative local. Dieter
participants (2)
-
dee900@anusf.anu.edu.au -
Dieter Maurer