My way of using Dan’s pattern is to define all public properties (not methods) in the object __pthis:

function Image(width, height)
{
// standard header
this.__pthis = {};
var pthis = this.__pthis;
// end standard header
//
pthis.width = width;
pthis.height = height;
//
this.__construct();
}

And then in a method I can do:
function multiply()
{
var pthis = this.__pthis; // standard line for all the methods to make __pthis local variable
return pthis.width * pthis.height; // example of how to access the properties
}

So I’ve got only one public variable __pthis (except for the public methods) and its easy to remember not to touch it from the outside code.

When I call one method from another method I use myMethod.call(this, arg1, arg2) as Dan recommends, to pass context. For me there’s the only inconvenient thing in that pattern I have to do – using call() method to call my methods. But I have the maximum speed and memory saving (it can be good especially for mobile devices).

I moved your comment to the analogous post here. Let me take your comment in two parts.

First, regarding my approach: you’re correct – in this case I’m trading memory for speed. At any given time we may not be utilizing all of the objects in the Pool. However, I’m circumventing the need to allocate and deallocate these objects, as well as avoiding the need to compact my GC heap.

Regarding the standard API: the scenario I believe you’re proposing is one in which identical (in meaning) objects are being requested, is this correct? For example, 25 users each ask for the homepage, which causes 25 identical homepage objects to be retrieved and served up? In this scenario, it is indeed wasteful; there are obviously better ways to cache these data than by using a simple pool without knowledge of the use of the objects.

As with any tool in a programmer’s toolbelt, you have to consider what and how you’re using the tool. In the case that I’m describing, I needed to allocate byte arrays to later read, all internally, for my API, and then to surface objects that corresponded to these byte arrays. I allocated the objects that my API produced, but since I never needed to worry about object identity with the byte arrays (use them then get rid of them), it produced a substantial performance benefit to my application.

I came across your article (http://robpaveza.net/speedy-c-part-2-optimizing-memory-allocations-pooling-and-reusing-objects) while searching for ways to optimize C# object references and cache eviction algorithms.

I read your article with interest and was wondering about the Pool class. Over the course of the lifetime of the app domain, unless I’m mistaken, you’re trading time released by less GC overhead with increased memory usage (all those pointers in Pool add up).

Imagine a standard API where a large number of threads each query the API for objects (i.e. enumerate hierarchical relations etc.). The Pool would ensure that if one thread at some point had freed an object, it’d be available for other threads to pick up. If you’ve got 25 concurrent threads working, each asking for the same objects (which would be typical in large scale website scenarios – disregarding output caching here), then each object could potentially allocate up to additional 25x space for pointers.

What kind of frequency are we talking about here, that justifies Pool and not just a ConcurrentDictionary?

Thanks in advance,
Anders Borum (Denmark)