Re: Glimpse.pm anyone?

[Sam Tregar <sam@tregar.com>]

On Tue, 16 May 2000, Doug McLaren wrote:

> On Tue, May 16, 2000 at 05:28:35PM -0400, Sam Tregar wrote:
> 
> | No, I mean calling into glimpse from Perl.  Basically, I'd roll glimpse as
> | a library and link it with some interface code to make it callable from
> | Perl.  That way instead of doing something like:
> | 
> |    $results = system('glimpse -C search');
> 
> Which probably wouldn't do what you wanted anyways.  Were you thinking
> of back-ticks?

Yes, you're right of course.

> This bit of code takes a fraction of a second to run.  The glimpse
> executable itself runs for several seconds at best and several minutes
> at worst (searching huge amounts of data.)  In my case, the fork/exec
> overhead is minimal (less than 1%) compared to the resources used by
> glimpse itself.

I wonder...  My case involves forking an Apache process that could be
around 20MB in size.  Of course, if glimpse does internal fork/execs then
it's pretty much a moot point anyway.  You're probably right that it's
not a large percentage of the runtime of any given search.

> To do what you're suggesting would require rewriting glimpse (or
> perhaps a crippled glimpse that can only work by talking to
> glimpseserver) either in perl, or into a shared library that could be
> loaded by perl.  Either case could be a lot of work.  Or maybe not :)

I was imagining using a tool like SWIG to wrap up the existing glimpse
code in a thin layer of interface.  Depending on how glimpse is written
this could be anywhere from easy to quite hard.  A lot depends on how it
does its memory management, among other things.

>From what I've heard here so far the project doesn't look all that
beneficial.  It would have a rather minimal performance benefit and it
could potentially be a difficult job.

Thanks for the advice!

-sam