[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] The exebuf, and asynchronous loading

On Wed, 29 Nov 2006 07:14:50 +1000 David Seikel <onefang@gmail.com> babbled:

> On Tue, 28 Nov 2006 21:44:37 +0200 Виктор Кожухаров
> <vkojouharov@gmail.com> wrote:
> > A few months ago, I asked raster if it would be possible to make the
> > code that searched for the executables in it's own thread, since with
> > a large PATH variable, it would take quite a while to find any
> > matches, leaving E totally unresponsive. While he told me that it
> > wasn't possible, he still made finding the executables asynchronous,
> > so it didn't block the UI anymore.
> > 
> > Now, with the new .desktop handling with the icons, another problem
> > has arisen. Basically, it takes a long time (1s+) to find desktop
> > icons for the matched executables, which blocks the UI. I'd like to
> > make the necessary changes to fix this issue, the way raster did back
> > then. However, I've no idea what he did, my only guesses would be
> > that an ecore job or an idle handler might do the trick. I'd like to
> > ask if any of the two can be used to update the icons asynchronously,
> > and if not, what else can I use to do the job right?
> I have discussed asynchronous icon searching with raster before, and I
> even implemented it once, but he vetoed that idea and removed the
> code.  Some of that code is still in there.  I have sped up the icon
> finding process across the board though.  Exebuf spends most of its
> time searching for the list of matching .desktop files rather than
> searching for or loading up icons once it has that list.

we could still have a on-disk cache for sped up .desktop and icon search
results - we still haven't done that yet :)

> I have plans to use some sort of data structure to speed up the exebuf
> matching process.  This would be a much better fix than making it
> asynchronous, as you not only get better response time from the rest of
> E, you also get quicker search times from exebuf.
> The real problem is that we are doing a linear search through several
> lists that includes wildcard matching at both ends of the search
> string.  I sped up the border .desktop matching by splitting the search
> into two lists, the majority with no wildcard that could be done by a
> hash, and the very few wildcards done by a linear search.  This trick
> wont work here because all searches are by wildcard.

and if that list of .desktops is long enough - that can slow things down. per
character you type. exebuf could defer the lookup though so it might not do it
per character you type (add a small delay so you can type several keystrokes in
before a lookup happens). this should be a very quick and easy improvement to

> Some sort of trie might work here, I am still investigating, but it has
> been a low priority task for a while.  We need something that can allow
> very fast matching of a partial string against a fixed list of full
> strings.  The match is not anchored at either end of the string, which
> is the tricky bit.  Inserting speed is not so important, we do that
> only once, and it can be done asynchronously at startup time, or even
> cached on disk.  Removal and reordering / reindexing speed will never
> be an issue.

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)