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

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



2006/12/2, The Rasterman Carsten Haitzler <raster@rasterman.com>:
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
usability.

> 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.
>


I'm writing a small app and I have the same problem; how to get an app
icon fast. After watching how does e17 handle data and icons in the
file e_apps.h, I noticed that there is no library I can use to re-use
that code, because it's very common that app use data from executables
which are installed. isn't better to create a library type ecore_xxxx
which offers access to data that e17 obtains from E_App structure ?

Greetings and big work. :-)