[Qt-creator] about the clang parser backend

[René J.V. Bertin]

Hi,

I've been looking with a bit of envy at Qt Creator's out-of-process clang-based parser architecture, which would be very nice to have in KDevelop too. Or maybe I should say "could be" because I don't use Creator enough to know for sure :)

One advantage I see for using a server/client backend approach instead of calling into libclang directly is that several IDE instances (sessions) could share the same server, thus decreasing memory overhead (clang can be quite memory hungry). Is there a technical reason why Creator doesn't do this but instead starts session-specific backends(s)?

Thanks,
R.

[Nikolai Kosjar]

On 12/4/18 10:04 AM, René J.V. Bertin wrote:
> One advantage I see for using a server/client backend approach instead of calling into libclang directly is that several IDE instances (sessions) could share the same server, thus decreasing memory overhead (clang can be quite memory hungry). Is there a technical reason why Creator doesn't do this but instead starts session-specific backends(s)?

There is no technical reason for this. The session-specific approach was
just the simplest one to implement.

I'm also not sure how popular the multiple-qtcreator-instances-running
case is as it can be problematic for settings.

Whether you can save a significant amount of memory with a
cross-session-backend depends on what data you keep in the backend and
the degree of precision you go for.

For us, as the clangbackend manages the translation units of the files
you have open in the editor, a translation unit is the dominating unit
consuming memory and each translation unit is quite separate/isolated
from another (that's how libclang works), and clangbackend does not deal
with project-wide indexing, there is not much that could be shared right
now.

Nikolai

[René J.V. Bertin]

On Tuesday December 04 2018 14:32:21 Nikolai Kosjar wrote:

> I'm also not sure how popular the multiple-qtcreator-instances-running
> case is as it can be problematic for settings.

KDevelop has no issues with this, as long as you don't open the same project in multiple sessions :)

> For us, as the clangbackend manages the translation units of the files
> you have open in the editor, a translation unit is the dominating unit
> consuming memory and each translation unit is quite separate/isolated
> from another (that's how libclang works), and clangbackend does not deal
> with project-wide indexing, there is not much that could be shared right
> now.

That would be a good reason not to bother. I was going to mumble something about TUs but then I remember I don't really want to know more about them :)
What's that about project-wide indexing though? How does that come into play in the context of multiple projects or sessions sharing a single clangbackend?

R.

[Marco Bubke]

The indexing is not holding any TU but simply indexing and then it throws the TU away. Everything is saved in a database which can be shared but I so far this is not supported. I think open the same project in different IDEs is not a common use case and we should not invest in it. There are more important tasks.

________________________________
From: Qt-creator <qt-creator-***@lists.qt-project.org> on behalf of René J.V. Bertin <***@gmail.com>
Sent: Tuesday, December 4, 2018 4:23:14 PM
To: Nikolai Kosjar
Cc: 'Qt-***@qt-project.org'
Subject: Re: [Qt-creator] about the clang parser backend

On Tuesday December 04 2018 14:32:21 Nikolai Kosjar wrote:

> I'm also not sure how popular the multiple-qtcreator-instances-running
> case is as it can be problematic for settings.

KDevelop has no issues with this, as long as you don't open the same project in multiple sessions :)

> For us, as the clangbackend manages the translation units of the files
> you have open in the editor, a translation unit is the dominating unit
> consuming memory and each translation unit is quite separate/isolated
> from another (that's how libclang works), and clangbackend does not deal
> with project-wide indexing, there is not much that could be shared right
> now.

That would be a good reason not to bother. I was going to mumble something about TUs but then I remember I don't really want to know more about them :)
What's that about project-wide indexing though? How does that come into play in the context of multiple projects or sessions sharing a single clangbackend?

R.

[René J.V. Bertin]

On Tuesday December 04 2018 16:14:13 Marco Bubke wrote:
> I think open the same project in different IDEs is not a common use case and we should not invest in it. There are more important tasks.

To be clear: I was neither suggesting any kind of support for opening the same project in different IDEs (Creator, KDevelop) beyond what already exists, and not even to open the same project at the same time in multiple copies of the same IDE. It would of course be nice to have persistent project-specific parsing information that speeds up operations when you reopen the project but in a way that's icing on the cake if the basic performance is fast enough.

That said, Creator does spend a considerable amount of time parsing, looking for tests. etc when you open a larger project (like its own sources) - a bit too much when you just want to open a project for a few quick checks or edits. KDevelop can be worse in this aspect but there you can deactive the full project-parse-on-open.

R