in reply to Time efficiency of object creation in Perl (or the "bless" function)
Your use model is not entirely clear from your post, so I can only speak from personal experience where I have had issues with method call performance across a large number of objects as well.
For this sort of thing, if I were using objects, I would likely adopt a slightly different design. The design you describe seems to be a simple data-driven design. Consider instead a responsibility driven approach.
My own responsibility driven solution was to incorporate "Set" container objects, composed of one or more "Data" objects. I implement most computation logic in the Set objects, and Data objects only contain data attributes, providing accessors. The Set classes inherit generic Set/aggregation functions from a base class for consistency, but function as "friend" classes of the specific Data classes. In my design, a "Car" object would be contained by a "CarSet". Treating "CarSet" as a friend class in my design allows/expects it to access the internal structure (hash) of "Car" directly, rather than through Car's accessor methods, which is what any non-friend class is limited to. Responsibilities between the Set and Data objects are very clearly defined, providing loose coupling, but the overall design is still very cohesive.
This structure allows (and hopefully influences) developers to optimize computation (or I/O) performance for multiple objects simultaneously, rather than individually. Individual objects can still be dealt with as an "army of one", constructing a Set on the fly to access computation/io methods. The structure also encourages development of reusable computation/io methods, driving that logic into objects as well, specifically objects that have special performance-by-design contracts with my data objects.
You can have objects and still have performance, but your design must accommodate performance requirements.
--Dave