On Tue, 28 Nov 2006 21:44:37 +0200 Виктор Кожухаров <firstname.lastname@example.org> 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.
Description: PGP signature