lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Profiling the indexing chain (was Re: KinoSearch3 tasks)
Date Wed, 16 Jun 2010 03:30:11 GMT
cc to lucy-dev...

On Wed, Jun 16, 2010 at 12:02:08PM +1000, Andrew Bramble wrote:

> I'm playing around with oprofile to see how to get some meaningful
> comparisons out of it, and devise a reasonable way to eliminate other noise
> while running benchmarks.

Sweet!

> >  perl -Mblib ../devel/benchmarks/indexers/kinosearch_indexer.plx \
> >    --docs=1000 --revs=30
> >
> > .... while OProfile is enabled, then report their results to the dev list.
> 
> I think that should read --reps=30 . 

You're right.

> I have some mixed results with the tags/ area , certain early versions of
> 0.30_* fail to run the benchmarks complaining;
>     Can't locate object method "clobber" via package "KinoSearch::Indexer" at
> ../devel/benchmarks/indexers/BenchmarkingIndexer.pm

Yeah, I had forgotten to update the benchmarking code for a few releases. :|
(There aren't any tests to verify that it workes).  

I can provide patches for those distros if you like.

> > Just running the benchmarker itself for those svn revisions would also be
> > helpful, and wouldn't require either Linux or OProfile.  I've been
> > implementing a number of optimizations, some of which have been more
> > successful than others, and it would be good to enter a record of how those
> > have gone into the dev list archives.
> 
> I will try to have some data and oprofile comparisons available this week.

It's been a while since I've had a chance to look at some profiling data.
This should be interesting.  :)  (I really ought to pursue access to a machine
where I can run OProfile myself, but it's hard to scrounge up a Linux box
around here where I get to be the only user.)

There are some specific recent changesets that I'd love to see data on.  I've
been making several changes to the indexing chain of late.

  * Calculate start_offset and end_offset for Tokens only if the field is
    highlightable.  That saves us some UTF-8 length counts (which necessitate
    full string scans).
  * Allocate/deallocate Tokens using a KinoSearch::Util::MemoryPool rather
    than malloc/free.  Freeing memory as one big block is considerably faster
    than calling free() many times for individually malloc'd blocks.  (We can
    deallocate Tokens en masse at the end of each Indexer_Add_Doc() call,
    because at that point they are no longer needed.)  This was a successful
    speed optimization, though it introduces API constraints I'm not thrilled
    about.
  * Have Tokens store pointers to shared text values rather than storing
    text data themselves.  This was supposed to be a speed optimization, but
    it has turned out to be a miserable failure.
  * Have Posting objects (which were already allocated using a MemoryPool)
    store shared term values, too.  That was supposed to be a speed
    optimization, but it did not yield the results I had hoped.
  * The Posting shared values are now opaque objects, which is a prerequisite
    for full introducing numeric field types like KinoSearch::Plan::Int32Type.
    This change cause a surprisingly large degradation in one method,
    PostPool_Compare(), because of an extra level of indirection.  I have a
    plan for working around this, but I'd love to see just how much time we're
    spending in PostPool_Compare() before and after the change.

Here are the svn revisions in question... we might start with r6138 as a
control...

    ------------------------------------------------------------------------
    r6139 | creamyg | 2010-06-07 08:21:57 -0700 (Mon, 07 Jun 2010) | 3 lines

    Optimize analysis by setting start_offset and end_offset only if necessary
    (which for now means only if the field is highlightable).

    ------------------------------------------------------------------------
    r6144 | creamyg | 2010-06-07 17:13:53 -0700 (Mon, 07 Jun 2010) | 4 lines

    Change Token to use a ZombieCharBuf to hold its text value.  This causes a
    30% indexing speed hit, but it's a necessary first step to sharing term texts
    across Token and RawPosting objects.

    ------------------------------------------------------------------------
    r6150 | creamyg | 2010-06-08 10:20:10 -0700 (Tue, 08 Jun 2010) | 3 lines

    Switch Token over to using shared terms.  This is another 10% indexing
    degradation.

    ------------------------------------------------------------------------
    r6151 | creamyg | 2010-06-08 10:23:29 -0700 (Tue, 08 Jun 2010) | 3 lines

    Take advantage of Token's shared terms to use pointer comparison rather than
    Compare_To() methods, clawing back 5% of indexing speed.

    ------------------------------------------------------------------------
    r6160 | creamyg | 2010-06-08 15:21:52 -0700 (Tue, 08 Jun 2010) | 3 lines

    Add Hash_Procure_Key() and switch token over to using it. (~%5 indexing speed
    improvement.)

    ------------------------------------------------------------------------
    r6175 | creamyg | 2010-06-09 17:53:14 -0700 (Wed, 09 Jun 2010) | 4 lines

    Convert all of PostingPool to use raw_posting->term instead of the text
    content encoded in raw_posting->blob.  PostingPool should now be compatible
    with non-text field types.

At this point, we're considerably slower than when we started!  We can get
back all of that and then some just be reverting the least successful changes,
but before we give up on these optimizations, it would be great to study them
in a little more depth.

Marvin Humphrey



Mime
View raw message