On 28 Jan 2010, at 10:45, Jonathan Kamens wrote:
> On 01/28/2010 03:49 AM, Ton Voon wrote:
>>
>> I'm wondering if there is a better way of doing this. Rather than
>> each caller having to work out the next comment id value and making
>> sure it is still unique, I think the next_comment_id should be
>> manipulated within xrddefault.c instead. If you call
>> add_new_comment with a comment_id of 0, it uses next_comment_id and
>> ensures it gets incremented.
> The right place to control the uniqueness of comment IDs is at the
> layer where comments are abstracted, i.e., comments.c.
Sorry, you are right. I was working from memory, which is not as good
as it used to be....
>> Can you extend the tests in t-tap/ to time the performance increase?
>>
>> So I'm thinking that the patch needs a bit more work to be applied.
> You may choose to accept the patch as is or not, but I will point
> out that although I clearly agree with you that there's a better way
> to optimize this code, the changes I made certainly do not make the
> code any worse than is now, and I would therefore argue that my
> changes are a net gain regardless of whether the other changes
> described above are implemented.
Fair enough. I think I'm just saying I'm not entirely happy with the
change to this, but if someone else wants to pick this up then they can.
>
> As for the testing, my goal here was to solve a specific problem for
> my organization, and to contribute the work I did on that solution
> (finding the bottleneck and optimizing it) back to the Nagios
> development team. As noted above, this is not really how I'm
> supposed to be spending my time at work, so I'd prefer if someone
> else added the test case.
Thanks - I appreciate your patches that you send back. But I'll say
for the record that a good test case makes the arguments for code
inclusion a lot easier
Ton
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]