Actually I regard the current behavior as a feature. Using a stopwatch and a
slide-rule I can estimate to within 100 objects, how many values are indexed
in a catalog by measuring the time it takes to draw the indexes page.
Please do not remove this most valued feature!
On Thursday 17 July 2003 04:35 pm, Dieter Maurer wrote:
> Chris Withers wrote at 2003-7-17 11:12 +0100:
> > Has anyone noticed that the ZCatalog Indexes tab crawls if you have loads
> > objects indexed.
> > My guess is that some types of index take way too long to figure out how
> > objects are indexed. Anyone know which index types those could be?
> The one that provide the correct number of indexed objects
> (rather than just the number of indexed terms).
> Because the same object can be indexed under several terms,
> determining the number of indexed objects requires to
> build the union of all the index values. This almost surely
> has quadratic (worst case) runtime characteristics.
> > BTW, would anyone object if I removed that object count, since it's not
> > very useful...
> You probably should replace it with the size of the index (i.e.
> the number of index terms).
> Formerly, the index overview displayed this information but
> under a buggy "# objects" title. Someone fixed this for most
> indexes, they now show the number of objects but at a high
> I suggest to change the title to "# index terms" and
> revert for the indexes to the old behaviour.
> Others pointed out, that also the size determination for an
> index may be expensive. However, it is at most linear in the number
> (rather than quadratic) and all recently created indexes now
> use "BTrees.Length" to maintain their size (which gives constant time).
> Having a feeling how large an index is is valuable information.
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -