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

[Scott McKellar]

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

<snip>

> Heh, I would hardly call that scheme fancy! :)
> 
> 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>

The attachment is my test harness.

I tried adding some code in osrf_json_object.c to keep track of how
long the free list is, and limiting it to a fixed maximum, as I
proposed earlier.  The increase in runtime was hard to see amid the 
statistical jitter, but appears to be no more than a few milliseconds,
out of about a second in toto.

I also repeated the experiment of isolating the allocation code in
a single function that's called from two places.  This time I was 
unable to reproduce my earlier results, or at least what I remembered
as my previous results.  Instead of an increase in runtime to about
1.6 seconds, the increase was negligible.

I'm not sure what happened.  I suspect that at some point I had
misread microseconds as milliseconds, or something.  Feh.

Conclusions:

1. We have more elbow room than I had thought for making the memory
caching code more sophisticated.

2. We should isolate the allocation code in a separate function after
all, especially if it's going to become more complicated.

If you like, I can send you my current version of osrf_json_object.c,
with a simple limit on the length of the free list and a single
allocation function.  I can send it whole or as a patch, your choice.
However tonight's additions are pretty simple, and you can probably
do it yourself faster than you can get it from me.

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

Developer's Certificate of Origin 1.1 By making a contribution to
this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated
in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source license
and I have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the
same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person
who certified (a), (b) or (c) and I have not modified it; and

(d) In the case of each of (a), (b), or (c), I understand and agree
that this project and the contribution are public and that a record
of the contribution (including all personal information I submit
with it, including my sign-off) is maintained indefinitely and may
be redistributed consistent with this project or the open source
license indicated in the file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timejson.c
Type: text/x-csrc
Size: 1838 bytes
Desc: 4051463629-timejson.c
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20071204/8f40f88a/timejson.bin