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

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



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.

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.

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.

Attachment: signature.asc
Description: PGP signature