elementary-dev-community team mailing list archive

[Lochlan Bunn <loklaan@xxxxxxxxx>]

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 <optimisme@xxxxxxxxx> 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 <david@xxxxxxxxxxxxxxxx>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 <loklaan@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>