Review Request: Enforce parse-jobs to be processed in order of their priorities

[Milian Wolff]

> On Feb. 21, 2012, 9:44 p.m., Milian Wolff wrote:
> > I don't like the way this idea is implemented. The api is clutterred with implementation-specific changes that should be hidden (e.g. via Q_PRIVATE_SLOT or similar). the "own priority" could be stored in a QMap<int, ParseJob*> that would allow fast lookup of the "best priority" via map.begin().key() (lowest value == highest priority).
> > 
> > Aside from that I don't like the fact that we will end up with cases where our parse threads are not doing *anything* just because some document is waiting for a reparse. Is there really no other way to solve this issue?
> > 
> > And at the *very* least I'd like to see some benchmarks (before/after) and would probably have to profile it on my own using vtune or similar to figure out the impact of this approach. But I'm pretty sure that the linear search you have there is killing performance.

just remembered another point heavily opposing this approach: the currently active document is always added with high-priority to the background parser, which would - with this patch - always trigger a thread-starvation. so nope...


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104019/#review10811
-----------------------------------------------------------


On Feb. 19, 2012, 2:40 p.m., Sven Brauch wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104019/
> -----------------------------------------------------------
> 
> (Updated Feb. 19, 2012, 2:40 p.m.)
> 
> 
> Review request for KDevelop, Milian Wolff and David Nolden.
> 
> 
> Description
> -------
> 
> As recently discussed on the mailing list, it is currently unnecessarily difficult to handle the following scenario:
> File A does something like "import B"; you want A to be parsed with the top-context for B available.
> Various language plugins have various solutions for this problem, but none of them were considered optimal by their creators (as far as I understood).
> 
> This patch aims to adress that problem. It changes the parsejob creation algorithm by enforcing it to wait with creating a job with a worse priority as long as jobs with a better priority are still running. Example: Three documents A, B and C are scheduled for parsing, A and B with priority 0 and C with priority -1. Assuming two parse jobs are available, the old function would create two parsejobs for C and A or B (let's say A), then wait for one of them to finish, then create a third job for B. The new function will create a parsejob for C and wait until that one is finished, and then create two jobs for A and B (still simultaneously, because they have the same priority). In other words: It's guaranteed that all parse jobs running at any specific time have the same priority. (*)
> 
> Why is that useful? Because parsejob priorities can be used to adress the above problem now: Let priority(x) be the priority of the parse-job for document x. You can then parse A, and as soon as you encounter the "import B", you can schedule B with priority(A)-1 and schedule A (again) with priority(A). That's now guaranteed to first parse B and then re-parse A with the top-context for B being available.
> Oh, this patch also adds a function to get a parseJobs ownPriority(), that wasn't available before.
> 
> Please tell me what you think.
> 
> Greetings,
> Sven
> ________
> (*) I'm aware of the fact that this will decrease performance by a little bit. However, I'm pretty sure it's not relevant. If the general concept of this is accepted, I'll test it.
> 
> 
> Diffs
> -----
> 
>   language/backgroundparser/backgroundparser.h 954ee17 
>   language/backgroundparser/backgroundparser.cpp 7210254 
>   language/backgroundparser/parsejob.h 135319c 
>   language/backgroundparser/parsejob.cpp 552ef68 
> 
> Diff: http://git.reviewboard.kde.org/r/104019/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120221/a7cc5e5c/attachment.html>