Re: Live Search

On Wed, Dec 9, 2009 at 17:35, Stewart Lord <stewey@ambitious.ca> wrote: > > On 9-Dec-09, at 5:37 AM, Hannes Magnusson wrote: >> >> Considering the "original" does over 7000 stat()s per request I can't >> believe a sqlite search on a small database can possibly be that slow. >> Are you 100% sure these numbers are accurate? > > It certainly wouldn't hurt to have someone else test it out. The "original" > only does the stat's on the first request. Subsequent requests hit a cache. > The cache is just a 300k serialized array of function/class names so it's > pretty quick to read through. Ahhh. I thought it was original original, as in what is in used today :) > We could combine the two approaches. Use the database to generate the > function cache. This might be a bit cleaner than scanning the directories, > but the result should be the same. Would that help? After all, that PhD generated database contains everything that people would want to look for (with the exception of full text search), so selective caching of just a small portion of it feels wrong. Offloading it to the client however feels better as it'll still do the xhr, but the initial results would be whatever the client has locally. >> We could offload some of the searching to the client itself, >> populating things like function/method index into json objects and >> cache it on the client, similar to what we do on >> http://people.php.net >> That should drastically speed up the basic search. >> >> We could look into how much data we can push to the client gzipped.. > > I toyed with this idea a bit. The function cache becomes 300k of > (uncompressed) JSON. My initial thinking was that this would take longer to > send to the client than it would for us to process server side. I'll bet thats under 100kb compressed. That cache would be the last thing to be loaded so I dont think a user would notice it at all. -Hannes