Opening large projects is terribly slow

[marc0777]

When opening a large project (such as Marlin) the IDE tries to load every single file inside the project folder, but after a certain number the opening of each file takes a couple of seconds.

Steps to reproduce the behavior:

1. Open Arduino Pro IDE
2. Open a large project
3. Wait

In my opinion when opening a project just the .ino file should be opened, or at most the files in the root of the projects, and not in subfolders. This way only essential files are immediately opened, and other files can be seen in the Explorer.

I doubt anyone would be using Classic mode for large projects, the drop down menu gets annoying to use with a lot of files.

Device:

• OS: Windows 10 2004, build 19041.572
• Version: Nightly 20201022

[kittaakos]

Thanks for logging the issue.

When opening a large project

Can you please share a link? I want to check the performance.

In my opinion when opening a project just the .ino file should be opened, or at most the files in the root of the projects, and not in subfolders. This way only essential files are immediately opened, and other files can be seen in the Explorer.

Well, we open all the files by design. Later, we might want to make this configurable, but it's not yet planned. I am turning your bug report into an enhancement.

For sure, opening a large project must not slow down the app causing a bad UX.

[marc0777]

The project I was trying to open is Marlin. The Arduino project is inside the "Marlin" folder of the repository.

It makes sense to consider it an enhancement, I was undecided myself. However the slowness makes very difficult working with large projects.

I would be very glad to help, will this project be opened sooner or later?

[kittaakos]

However the slowness makes very difficult working with large projects.

I agree. It is unusable. Also, opening 1632 files besides the main sketch file makes no sense. Thank you again for the heads-up on the performance issue.

[ubidefeo]

@marc0777
I have compile Marlin from the CLI, never opened it in the IDE (it scares me).
The project will be open in the near future, before we do so we'll have to make sure it's well documented, clean, and ready for the community to start collaborating.
It is taking us a bit longer than expected, but we'd rather have the bulk of functionalities ready before we throw it out there :)

[ubidefeo]

@kittaakos
I digged into this, and I think we're handling the file opening wrong.
Over the years Marlin has transitioned to compiling using PlatformIO (which is recommended by them).
The project has been rearranged to contain the src folder but leaving a source-free (comments only) .ino file in the main Sketch folder in order to allow compilation through the Arduino Java IDE.
I hadn't realised where this issue lied because I mostly use the CLI, which happily compiles Marlin for the Arduino Mega or other compatible target boards.
When you open this project in the Java IDE it will not load the content of the src folder (but will compile it anyway).
We should not automatically drill down subfolders but just display what's in the main Sketch folder.
I'll therefore add the bug label to this issue ;)

[kittaakos]

We should not automatically drill down subfolders but just display what's in the main Sketch folder.
I'll therefore add the bug label to this issue ;)

I am using the LoadSketch gRPC API, it gives me back all the 1633 files including the main sketch file.

I am adding the CLI label.

[kittaakos]

For the time being, we could add a preference for whether to open all sketch files or only those that are at the root of the sketch. Opening all files could be the default, no behavior change, but users can still adjust it. Thoughts? We could tackle the UX issue without a CLI change.

[marc0777]

For the time being, we could add a preference for whether to open all sketch files or only those that are at the root of the sketch. Opening all files could be the default, no behavior change, but users can still adjust it. Thoughts? We could tackle the UX issue without a CLI change.

I think that would be a good solution. The preference could let users choose between the default of opening all files, an option to open only the files in the root, and the last one to open only the .ino files.

For sure the last one would be the one I'd use the most: I think starting from a clean workspace when working with big projects is important, and it would save the time to close all the opened files.

[ubidefeo]

@marc0777
we're reworking how you display the sketch's local file structure, so a few things will sure change sooner than later.

The preference could let users choose between the default of opening all files, an option to open only the files in the root, and the last one to open only the .ino files.

this might cause the issue you're having right now if such preference is set by the user and a large project like Marlin is opened.
I'm leaning towards letting the user "manually" opening files in sub-folders, but we'll have to see with our UX people how that would work and look.

For sure the last one would be the one I'd use the most: I think starting from a clean workspace when working with big projects is important, and it would save the time to close all the opened files.

my point exactly :D

Thank you for the feedback
u.

[Dave528]

I think it would make sense to allow the options you give here:

For the time being, we could add a preference for whether to open all sketch files or only those that are at the root of the sketch. Opening all files could be the default, no behavior change, but users can still adjust it. Thoughts? We could tackle the UX issue without a CLI change.

However, would it not make sense to just have the IDE remember which files you had open last time the project was opened? Many IDE's use this method to allow users to pick up where they left off.

[ubidefeo]

@Dave528 I was having a somewhat related chat with @facchinm the other day.
we definitely need to address this because in large projects it can turn into a sluggish process.

keep your eyes peeled, we have a couple of things in progress which should help when added to the release.
Unfortunately I don't have an ETA to share with you, the project is moving forward and Nightly builds show that, but we're a bit slow on official releases during this Alpha stage

[per1234]

Closing as fixed by d1505f2
Thanks Akos!