Keep in mind that the search terms may change even while the search is running or can be aborted. So I'd recommend you to have good communication with your threads. ;) Il giorno 14/set/2013 02:32, "Lochlan Bunn" <lokl...@gmail.com> ha scritto:
> Thanks for the input guys, I really appreciate it. > > *David*, > You're right, the search app could benefit from parallelising some of the > search functionality, not that it isn't pretty fast already. It would > involve dividing the amount of work (searchable directories) into chunks > depending on the particular machines cpu, and then pushing those chunks to > threads, with different cpu core affinities, for them to process the work > in parallel. The work could be synced back after each thread is done, or > during (this would cause alot of locks and waits though). > > The thing is, it would need to index all of the file systems available > directories into the utilised struct before splitting the search work; this > work can also be split up in parallel by top directory. Or, use some > existing structure provided by some linux service; I don't know about this > but I assume there would be something available. I am liking this idea and > search is generally a good thing to parallelise, but I'll have to get in > contact with my professor before going ahead with it. So, I'll definitely > be considering this! Thanks! > > *Albert*, > Thanks for the suggestions and advice! I actually really like the idea of > improving the animation within marlins breadcrumb. However, I haven't > finished reading the relevant source so I can't give much commentary on > benefits/reasons. > > I think the elementary guys are using existing search and indexing > packages for things like slingshot, so I don't think it would be much use > looking into it. Anyway, thanks again, I appreciate your help! > > *Julien*, > I went and reread this page after you first linked it, which was a good > thing because I missed the mention of GLibs AsyncQueue the first time > round. Thanks for the advice! > > > If anyone still has some knowledge to spill on the matter, I would really > appreciate it! > > > On 10 September 2013 20:13, Albert Palacios <optimi...@gmail.com> wrote: > >> Hi, >> >> Here are more ideas: >> >> - Do not mix threads with async methods, sometimes GUI is fluid with >> async and threads are not necessary. Maybe both concepts are interesting >> for your research. >> >> - Pantheon-files has parallelizing problems with thumbnails and top >> navigation bar animations (I am not sure if this is a clutter problem), but >> it can be improved. >> >> - (As far as I know) Granite library lacks functions to easily create >> threads or async methods, for example to load images/textures for clutter >> without blocking animations. >> >> - I don't know how advanced is the work of "search" and "indexing" tools >> for Isis, but both will need a lot of parallelization optimizations to >> maintain Luna's performance. >> >> Albert >> >> >> >> On Tue, Sep 10, 2013 at 11:58 AM, David Gomes <da...@elementaryos.org>wrote: >> >>> Hi there, >>> >>> A mate and I worked on this search app together: >>> >>> https://github.com/gangsterveggies/ancel-search-tool >>> >>> It's not an official elementary app but it follows the elementary HIG >>> and uses Vala/GTK3/Granite like elementary apps do. >>> >>> We wanted to make the Search asynchronous and have one thread for the >>> search and one thread for the GUI. We stopped working on it, but if you >>> want to contribute with something like that (which I believe is somewhat >>> related to parallelizing) feel free to, I'm Munchor on #elementary-dev if >>> you need any help. >>> >>> Of course, I might be very wrong and this has nothing to do with >>> parallelizing. >>> >>> ~David >>> >>> On Tue, Sep 10, 2013 at 5:13 AM, Lochlan Bunn <lokl...@gmail.com>wrote: >>> >>>> Hello everyone, >>>> >>>> For the next few months I am to base a uni project on parallelizing an >>>> existing program (or part of). I'd like to use this chance to contribute >>>> *something* for the elementary project. >>>> >>>> So, are there an elementary/community app maintainers that would know >>>> of some task that would benefit from being parallel? It would be better if >>>> the kind of task had significant improvement potential. If you're not sure >>>> about the potential, I would still be interesting in being contacted. >>>> >>>> Past reading documentation for vala, I'm not at all experienced in >>>> using the language. But any memory model and parallelization specific >>>> problems I find, I could approach the vala community. If you're suggestion >>>> is using C and pthreads, then that could actually be better for both this >>>> projects requirements and depth of contributed performance gain. >>>> >>>> Thanks for reading. I hope to hear back from some people! >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>> Post to : elementary-dev-community@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> -- >>> Mailing list: https://launchpad.net/~elementary-dev-community >>> Post to : elementary-dev-community@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> > > -- > Mailing list: https://launchpad.net/~elementary-dev-community > Post to : elementary-dev-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~elementary-dev-community > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
