I think it might be a good idea, before progressing to the beta phase (which will hopefully take less time) to profile the module (especially searching – indexing is usually not as time-critical, I'd say) and see whether there are any areas which can/should be optimized or which use up unexpectedly much resources.

Comments

drunken monkey created an issue. See original summary.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

Postponed because it makes sense to wait for the other beta blockers to be resolved, first.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Postponed » Needs review

I've now profiled the module with a moderately-sized site (for the DB backend) – 2000 nodes, 2000 comments, 100 users, 100 terms.

The good news is that the search itself was still pretty fast (0.5 ms, if I read the output right – which I probably don't, though). The two major performance bottlenecks where rather small details, actually:
#2774407: Disable highlighting processor in the Defaults module
#2774415: Multi-load items for Views access checks
We should solve those, but I don't think either of them needs to be a beta blocker.

I also thought I'd spotted a bug in the Views "Rendered entity" row style, which seemed to ignore the view mode setting, but it just turned out to be a side effect of this:
#2774445: Text field summary should be filled with short text

Any comments to any of this? Does anyone else want to profile before Beta, to make sure we have no architectural problem slowing things down? Otherwise, I'd just mark this as "Fixed".

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
commented
Status: Needs review » Fixed

Those are some pretty good results, let's close this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.