On Thu, Feb 17, 2005 at 10:31:56AM -0500, Tac/Smokescreen wrote:
> Why does searching write into the index structures? Is it required? Does
> it cache the most recent searches in some way?
It doesn't cache results. That's something I've thought about often,
and way back when first thinking about a "swish server" was some
middle level that would cache results so that "page next" requests
would not require running the same query again (which is how it works
now). I've used Cache::Cache modules to write the entire result set
out to disk. Quite a bit faster than re-running the query, but I did
that because I needed to read all results on the first request for
other reasons (so already had the result list in Perl memory).
I think there are some API calls that return stings that don't need to
be freed by the caller. So, those strings are stored in memory and
freed when the containing object/structure is removed. Let
Well, the one I was thinking of stores the strings in a results data
structure, so that would be unique to the process.
SwishResultPropertyStr() caches properties in
db_results->prop_string_cache. So that might not be a problem.
(And frankly, it would be easy in API.xs to get the string from swish,
create a new scalar in Perl and copy, then free() the string from
swish. It's better to use SwishProperty() in Perl since it does
Seems like I remember that the stemming code does some caching, too.
Asking for the list of metanames or property names caches those
strings in the index. So asking for those would write into the (in
Again, it may be very OS dependent what the OS decides to copy.
What platform are you running on? Do you have good tools to show what
is shared vs. private memory?
Back in my youth, I used (I think it was called) pmap on solaris to
look at shared and private memory running under mod_perl and,
according to pmap, more private memory was used when I pre-loaded my
modules. Didn't make sense.
Unsubscribe from or help with the swish-e list:
Help with Swish-e:
Received on Thu Feb 17 10:31:26 2005