ForegroundLock

[David Nolden]

2011/1/9 Milian Wolff <mail at milianw.de>:
>> Anyway, this lock is mostly used for ligh-weight calls like
>> editor->getText(), and I am very sure that it doesn't have _anything_ to do
>> with nonresponsive UI. The duchain locks are much more problematic
>> regarding this.
>
> Exactly, they are lightweight. So we can do them once before pushing the job
> into the background and "forget" about it. But really, this is just my
> personal (theoretical) opinion, that it *might* result in a better perceived
> performance. If it is really the case or not is left to be seen.

They are only lightweight if you do one call at a time. This is what
happens with the foreground lock. As soon as a background thread
requires the editor text, the foreground will pause for a tenth of a
millisecond (only in case it's idle), just as long as the background
needs to do one call to "getText()".

If you want to collect a lot of stuff in the foreground before
starting the parse-job, then it will obviously lead to _more_ blocking
of the UI, because the foreground will be busy for a longer time than
just the call to "getText()" (which would be the only perceived
[actually unperceivable] pause using the foreground lock).

In any case, the foreground needs to be blocked when you call
"getText()", so the foreground-lock approach leads to the exact
minimum of UI blocking. I hope this helps understanding why I keep
repeating that "minimal", and I cannot see a gain by using another
pattern.

Also: It's very hard to collect all the data required for the
parse-job beforehand, because the parse-job may require the text of
documents which it will get to know only later during preprocessing
through #include directives.

> Right, I didn't talk about features or anything. Just about that they use the
> memory pattern and their editor is fast (yes no highlighting and all that,
> maybe it really is all that is to that). But don't take this too seriously
> until I really start coming up with patches and results that compare both
> approaches.

Regarding editor responsiveness, I'm also pretty sure that kate and
the moving-ranges are a big culprit (apart from our own
CodeHighlighting which adds them all at once). We're the only ones who
create thousands of moving ranges in each file. We probably should
speed this up, by only adding MovingRanges on-demand for those lines
which are currently visible in the editor. However kate doesn't expose
those lines to us yet.

Greetings, David