Menu
▾
▴
Re: [Jdbm-developer] performance metrics
|
From: Alex B. <boi...@in...> - 2005-10-07 21:57:27
|
+1, I believe we should separate the performance harness from unit tests. main() is just fine too. What I would be looking for is a single script to execute all the performance tests and get back a condensed report of all metrics which can be saved to a file for later comparison. alex 'Kevin Day ' wrote: > Alex- > Good question. I have the test procedure I used during my development, > but it isn't strictly a test harness. > > I think that we all started (but never finished) a discussion > about splitting performance tests from unit tests. This would obviously > fall under the former. > > If we want to make a quick decision on that, I will adjust the test > structure and commit the performance test I created. Now that I'm > looking at it, the test class itself is actually a fairly generic > performance test harness for getting performance results of operations > against a record manager. > > I have two tests written that plug into the framework: Batch insertion > of records into the record manager, and batch insertions of records into > a BTree. > > Right now, the test is started from main() - I don't know if this is OK, > or if we want perf tests to be run in a JUnit context... Doesn't seem > like they should, but I'm certainly open to adjusting that. > > - K > > > > > Speaking of which, do we have a performance test to measure the impact > of this change? > > I know Kevin you've done some tests but I'm wondering if we should start > defining a performance test harness with specific metrics so that we can > assess the relative merits of changes to the algorithms/structures. > > alex > > > 'Kevin Day ' wrote: >> Bryan- >> I think you might be missing something. getFirstGreaterThan returns an >> available RECORD of a given size. My optimization has nothing to do with >> finding available records - it has only to do with finding open slots > in the >> list that holds on to available records. >> >> An open slot has no size associated with it, so you would never search > for an >> available slot of a certain size. getFirstGreater is COMPLETELY > different thatn >> getFirstFree. getFirstGreater searches the list for used slots of a > certain >> size. getFirstFree searches the list for empty slots. >> >> I agree that getFirstGreater needs to be fixed (in fact, it probably > needs to be >> completely thrown out and replaced with an efficient allocator), but my >> optimization will absolutely fix the performance hot spot of getFirstFree. >> >> Cheers, >> >> - K >> >> >> > Kevin, >> >> No problem. Enjoy your weekend. My point is that getFirstGreaterThan >> has different semantics than getFirstAllocated, resulting in scanning >> over allocated slots that do not satisify the size parameter. >> >> -bryan >> >> -----Original Message----- >> From: jdb...@li... > <mailto:jdb...@li...> >> <mailto:jdb...@li...> >> To: JDBM Developer listserv >> Sent: 10/7/2005 2:22 PM >> Subject: [Jdbm-developer] re: [jdbm - Open Discussion] RE: jdbm hotspot in >> (re-)allocation of record >> >> Bryan- >> >> Sorry I haven't been keeping up with your posts this week - it's a >> really bad week for work. >> >> I will review this email (hopefully over the weekend) and get back to >> you - but for now, I have put together a plan for addressing this >> bottleneck (and the FreeLogicalRodIdPage class) - the current management >> of the free lists is nowhere near as efficient as it should be. >> >> Note that the changes I made to FreeLogicalRowIdPage were directed at >> reducing the time it takes to find an available SLOT in the list (i.e. >> an available slot in which to place the reference to the free physical >> row id). The same situation exists in FreePhysicalRowIdPage, and it >> should have nothing to do with the size parameter - the search that I >> optimized is geared at managing open slots in the free list - not in >> actually determining which entry in the free list to pull during an >> allocation request. >> >> To do any optimization on the allocation of records, we need to get into >> the redesign of the allocator. I'm still quite fond of the idea of >> using a set of linked lists, one for each size range, that the allocator >> can quickly pull from. >> >> I'll catch up on all of the posts soon - sorry for the delay. >> >> Cheers, >> >> - K >> >> >> > >> Read and respond to this message at: >> <https://sourceforge.net/forum/message.php?msg_id=3372174> >> https://sourceforge.net/forum/message.php?msg_id=3372174 >> By: thompsonbry >> >> Kevin, >> >> I've started looking at the FreePhysicalRowIdPage class. The changes >> that you >> made to FreeLogicalRowIdPage do not carry over directly since the test >> is not >> for an "allocated" slot, but for one which is allocated and where the >> record >> has at least a given size. >> >> I tried out the same method anyway, but it results in both more time >> (slower >> execution) and more space (larger store) since it is skipping over >> allocated >> slots for free physical records which do not satisify the current >> request, but >> which might satisify a subsequent request. >> >> I'm going to think about some alternative approaches that we might try >> here. >> For example, maintaining a more complex transient data structure than >> the two >> counters you added to FreeLogicalRowIdPage or reordering the slots so >> that the >> slots are dense and sorted by size, in which case we could just use a >> binary >> search for both getFirstFree() and getFirstGreaterThan(int size). We >> could >> re-order when slots are freed or allocated. >> >> There may be other solutions as well, but I would like to resolve this >> bottleneck. >> >> -bryan >> >> ______________________________________________________________________ >> You are receiving this email because you elected to monitor this forum. >> To stop monitoring this forum, login to SourceForge.net and visit: >> <https://sourceforge.net/forum/unmonitor.php?forum_id=12569> >> https://sourceforge.net/forum/unmonitor.php?forum_id=12569 >> >> < >> ------------------------------------------------------- This SF.Net >> email is sponsored by: Power Architecture Resource Center: Free content, >> downloads, discussions, and more. >> http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ Jdbm-developer mailing >> list Jdb...@li... > <mailto:Jdb...@li...> >> <mailto:Jdb...@li...> >> https://lists.sourceforge.net/lists/listinfo/jdbm-developer >> >> < >> ------------------------------------------------------- This SF.Net > email is >> sponsored by: Power Architecture Resource Center: Free content, > downloads, >> discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ Jdbm-developer mailing > list >> Jdb...@li... > <mailto:Jdb...@li...> >> https://lists.sourceforge.net/lists/listinfo/jdbm-developer > > > -- > Alex Boisvert, Product Development Director > Intalio, Inc. | www.intalio.com <http://www.intalio.com> > boi...@in... <mailto:boi...@in...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Jdbm-developer mailing list > Jdb...@li... > <mailto:Jdb...@li...> > https://lists.sourceforge.net/lists/listinfo/jdbm-developer > > < > ------------------------------------------------------- This SF.Net > email is sponsored by: Power Architecture Resource Center: Free content, > downloads, discussions, and more. > http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ Jdbm-developer mailing > list Jdb...@li... > https://lists.sourceforge.net/lists/listinfo/jdbm-developer -- Alex Boisvert, Product Development Director Intalio, Inc. | www.intalio.com boi...@in... |