Skip to main content.
home | support | download

Back to List Archive

RE: Re: Swish-E New Feature?

From: Scott Schultz <scott(at)not-real.ceweekly.com>
Date: Fri Jan 22 1999 - 19:49:43 GMT
On Wed, 20 Jan 1999, Valerio Gelpi wrote:

>> I was wondering if you are planning to add the feature to be able to have
>> multiple result pages. I was able to implement such feature thanks to
Scott
>> Schultz (scott@ceweekly.com) changes to a few Swish files. I would
>> assume such a feature to be natural for this program.

To which Roy Tennant replied"
>We were thinking that this function could logically reside outside
>SWISH-E, in the hands of the program manipulating the results. What do
>others think about this?
>Roy

My $.02;

On the face of it, you're correct. My experience (and the reason that I
wrote
the patch to skip X initial results) was that the performance gain was a
lot higher if swish-e set the initial starting point for me.

Consider a search that returns 1000 results. I want to present these results
to the user 100 at a time. No problem. I just stick the results in an array
in Perl or PHP and start at the X-hundredth element, or I read the output
and
skip X-hundred lines. Since I don't have state maintained between pages
I have to do the search again on each page in order to display the next page
of
results.

What I found was that doing the search ten times was not nearly as
time-consuming
as reading all the results ten times and "positioning the cursor", to borrow
some
database parlance. Swish-e already has -m to restrict the number of results
displayed.
It was a natural fit (IMO) to add a parameter to tell where in the results
list to
start the display.

By having swish-e return only 100 results each time, (by skipping to the
current
start and then only displaying 100) my scripts don't have to read a lot of
data
that isn't neccesary and I don't have to allocate giant arrays to handle
large
sets of results if someone searches our jobs database for something generic
like
"software". The search is fast, the display is fast, and the only state I
have
to maintain is the current position of the "cursor" and the page-size.

It's a practical thing rather than an elegance thing. You're right about
it not being directly related to the index/search functionality of
swish-e. However, it is an extension of existing functionality (ability to
limit results) and it's needed for the same reasons that the -m flag
was needed. One could as easily argue that the -m functionality should be
handled by the wrapper script; it's just a heck of a lot faster and
less resource-intensive to have swish-e handle it instead.

Scott Schultz
scott@ceweekly.com
Received on Fri Jan 22 11:52:08 1999