On Wed, 29 Nov 2006 07:14:50 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> On Tue, 28 Nov 2006 21:44:37 +0200 Виктор Кожухаров > <[EMAIL PROTECTED]> 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. > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
