There was a similar discussion a few months back (I think the answer
on the es optimization side was that it wasn't practical, but I won't
speak for Shay).
What I do for a similar problem, which works completely fine for me,
is just to throttle at the interface side, with something like:
1] On keypress (/new word, whatever), check if there are any pending
1A] If not send a request
1B] If so, save this request (overwriting anything previously saved)
2] When a request returns, send out the saved request, if there is one
(Obviously you can play similar games on the rendering side if there's
a bottleneck there, ie only displaying the results from  if there
are no saved requests that will replace it, unless there has been no
update to the display for a given period)
This very simple algorithm prevents a build up of "old" requests. If
the latency is high enough that this doesn't work reasonably well, my
guess would be that the searches are too slow to be sensibly rendered
in real-time anyway!
On Jan 13, 12:10 pm, Vineeth Mohan vineethmo...@algotree.com wrote:
Are there any support for real time search like the one google have.
Not to be confused by the term real time search , what i mean was that
search results are displayed long before the entire term is typed.
What i am expecting is some optimizations in this area , may be something
like abandaning a request if another request (which came after ) from same
source is processed.