SPAM: Re: [OPEN-ILS-DEV] PATCH: osrf_json_object.c (miscellaneous)

[Scott McKellar]

--- Mike Rylander <mrylander at gmail.com> wrote:

<snip>

> For the sake of argument, the worst case (other than the
> cache-blowing
> "tear it all down" threshold, which I now think is needless) is one
> int comparison, one division, one float comparison and an increment.
> Division is far from free, but I bet it's cheaper than heap
> allocation.  In any case, we /do/ have a way to know for sure.  Would
> you mind sharing your test harness that shows the 3.5x speed-up? 
> I'll
> knock it around and see how much improvement we lose with my scheme.

<snip>

I'm at work right now, but when I get home tonight I'll send you my
test harness.  It's not polished, because I keep tinkering with it,
but you will probably do your own tinkering anyway.

Let me give some background for why I am reluctant to add more than
minimal overhead.

There are two functions that allocate jsonObjects.  In the patch I
sent you, I duplicate the allocation code.  I tried to make it 
prettier by pulling it into a common function to be called from two 
different places.  To my surprise, the extra overhead of a function
call eliminated a significant fraction of the performance gain.

With no caching, my test harness typically runs in about 3.5 seconds
on my machine.  With caching, duplicated as in the patch, it typically
runs in just under a second.  With the allocation abstracted into a
common function called from two places, it runs in about 1.6 seconds.

I don't know how much overhead your scheme will add, but it may not
take much to erase much of the performance gain.  I guess we'll find
out.

-----------

Let me suggest yet another approach.

Leave my original patch alone, but add a function call to prune the
free list to some specified limit.  For example if we call:

    jsonObjectPrune( 20 );

...then jsonObjectPrune() walks the free list and frees anything
beyond the first 20 nodes.

Advantages: It doesn't cost anything unless you actually call it.
By contrast, if we maintain and check a length variable, we incur
overhead with every allocation and deallocation, even in an
application that doesn't need that degree of control.

Compared to jsonObjectFreeUnused(), jsonObjectPrune() would trim the
fat without cutting into the lean.  We could redefine 
jsonObjectFreeUnused() as jsonObjectPrune( 0 ).

Disadvantages: it adds another knob, as you put it.  It also allows
the free list to become temporarily very large, even if we can prune
it later.  Of course in those situations the total number of mallocs
may not change, and it may not make much difference whether we free 
the excess before or after putting them on a free list.

--------

One final caveat: this kind of memory caching is inherently not
thread-safe.  It would be possible to make it thread-safe by adding
mutexes or critical sections or whatever, but that extra code would
almost certainly cost more than we would gain from the caching.

I see no evidence that Evergreen or OSRF will ever be multithreaded,
so I won't worry about it for now.

Scott McKellar
http://home.swbell.net/mck9/ct/