Project with many layered dependencies cannot use code completion due to timeouts.

[aubade]

In order to deal with some of the fallout that comes from using a lot of templates with D, i've divided my personal project into ten layered subpackages. Unfortunately, this has caused a complication; when I work more than three or four from the bottom of the stack, running through the dependency tree almost always causes Eclipse's Code Completion to timeout after three or four seconds.

I cannot find any setting in Eclipse's or DDT's user-side preferences for extending this timeout, and when working with something as complex as GtkD, code completion is almost a necessity. Is there anything that can be done on DDT's end to work around this?

[bruno-medeiros]

Hum, weird, there was a big performance problem with dense DUB dependencies, but it was fixed in 1.0.0 ... maybe there is another issue as well. Could you send an archive with the project that causes that slowdown, preferably simplified?

(and nope, there isn't any way to change the code completion timeout at this point. I could add that, but I think anything that takes more than 5 seconds would very annoying to the user, if not downright unusable.

[aubade]

Paring it down will take some work! it's a bit of an elephant.

While I work on that though, would it help that it uses secondary .json files rather than defining subpackages completely in the main .json? It's also being stored on a 5400 RPM hard drive, which might have slown things down a bit.

[bruno-medeiros]

Secondary .json files? Hum, yeah could be related to that. I wasn't aware of that feature up to now..

[bruno-medeiros]

I've given it a quick try with a complex project structure:

top_level_dub_package depends on subpackage8 subpackage8 depends on subpackage7 .. and so on until subpackage1 each subpackage also depends on a large library, like vibe-d

I tried a few different code completions - completion for vibe-d types, completion for types in subpackage1, completion for all import packages, etc., and I couldn't find any issues like you mentioned. I mean, a few operations timed-out the first time they were invoked, but all subsequent invocations were nearly instantaneous (because they now used cached values).

You'll have to narrow it down to a case I can reproduce.

[bruno-medeiros]

@aubade Someone else reported a similar problem with GTKD, I gave it a try and was able to reproduce, I think I got a fix too. Can you build DDT from master and give it a go, see if it works for you? From the changelog:

• Fixed: recurring timeouts invoking Content Assist and other engine operations with large projects like GTKD. (#143)
  • Now the timeout will still occur the first time Content Assist is invoked in a session, but the background engine analysis operation will not be cancelled: it will continue in the background, allowing the analysis to complete and future invocations to not timeout.

[bruno-medeiros]

Should be fixed (see also: https://groups.google.com/d/topic/ddt-ide/axQYj_Uh6gc/discussion )