GNAT Studio Editor Performance Problems

General
1

Summary: GNAT Studio code completion/outline slow when using very large package.

In GNAT Studio when viewing very large files, around 30-40k lines, I incur performance hits. The file size comes from a very large generated binding. I know that I could just separate the package into smaller pieces using ‘separate’, but I don’t want to do this. These bindings get swapped out, overwritten, and deleted all the time. I want to keep any manual interaction with it at a minimum.

Whenever I pull up the outline panel it looks like it reanalyzes the entire file every time I open it without any caching. I believe this is causing the biggest performance hit. Likewise, when I use code completion it feels slow, as I think it also isn’t caching as said above. The code completion for instance when typing ‘vkin[TAB]’ to get ‘vkinstance‘ to appear, gives a calculating popup for a few seconds(8ish) even though it supposedly already analyzed the file when I was looking at its outline a minute before. My computer may just be slow.

Is this something I should make a feature request for on the github repo?
Is my processor just in need of an upgrade?
Or is there a way to set the analysis ‘depth’ to be more shallow?

Anything helps. Thanks.

2

You can open an issue on GitHub, and attach your code. It is hard to guess what is happening on your side without details and reproducer.

Generally, you need to wait till indexing done, after that performance should be good enough. 8 seconds is bad.

3

I suppose you are using vulkada. File units are quite large with tons of type and constant/variable declarations directly in the root library file.

I experience the same things on my desktop but I thought it was my old computer…

4

To reproduce, just generate bindings for vulkan_core.c and with/use it in a file, then type ‘vkin’ and wait.

The 6-8 seconds is the repeated time I get. It does drop maybe 2-3 seconds, but still takes 5-6 seconds every time.

I am using vulkan, but not specifically vulkada, just the c of vulkan passed through the binding generator.

I’ll try to find some more info on this and reply here with an update if it led to a github request, or if I found something else.