Collections, messages, and blocks
I've been seeing a lot of code lately that uses select: and collect: messages to collections and you might be thinking, "yeah, Blaine what's the big deal, that's the way we do things!" Now, doing a collect:, select:, or anything else on small collections is fine, but what about when the collections get big? Things like a collect:, select:, or reject: become time consuming and huge memory suckers, since Smalltalk has to create a new collection for the new copy. Or does it? Since, we are just sending messages around and are encapsulated from the implementation of the collection that is returned by collect: or select:. Why not delay the calculation? Keep the block around and avoid calculating the new collection until absolutely necessary. I want to play around with this idea and see what happens. I'm thinking for small collections, it will cost more, but as the collection grows to be very large, the performance gain of not creating a new collection will be enormous. Or maybe not...Stay tuned...At the very least, having a language with lambdas (blocks) and dynamically typed gives one a lot of flexibility to think thoughts like this and try them out.
Sunday, February 08, 2004
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment