How best to define workspaces for server-side editing?

[RyszardWithAZ]

We have more than 20,000 .INT routines and also have thousands of classes. We start to have performance issues with this many objects in VSCode.

For me, having one namespace with the ISFS definitions split up between just classes and just routines seems to work fine.

However, once I add a second machine to that list, my Ctrl-P to open a specific routine slows to a crawl.

What's the optimal way of arranging this setup? Is it more performant to have one definition for "everything" per namespace? Or is breaking it up by classes & routines better? What about when there's a 2nd environment in the mix?

[isc-bsaviano]

Hi @RyszardWithAZ, there are a few things that might help:

• Remove generated=1 when you don't need it.
• Use the filter query parameter or a project to reduce the number of routines in the workspace folder.
• If Ctrl-P is the main source of performance issues, you can try the ObjectScript: Open InterSystems Document... command, which is in the command palette and is an icon in the title bar of the file explorer view. Unlike Ctrl-P, this command:
  • Is scoped to a workspace folder.
  • Doesn't try to load the names of all 10,000 documents in the folder if you haven't typed a filter string yet.
  • Allows you to type the full name of the document you wan to open (for example, %Api.Atelier.v8.cls) and press enter to open it, even if it doesn't appear in the pick list or isn't in your workspace. This means that you can hide generated files from the workspace, but still open one by name if you need it.

I am curious why you have a local folder in the same workdpace as your server-side ones. That shouldn't affect performance, but it's not something we recommend.

[RyszardWithAZ]

Thanks for the info. I unfortunately can't remove generated or filter down further because my product is basically "everything", and I need to many times reference & examine both generated classes & routines.

I tried using ObjectScript: Open... and that definitely works better, I will use it!

I don't know why I have the local folder anymore, I seem to remember years ago either VSCode or the ObjectScript plug-in required a local folder, otherwise the other isfs folders wouldn't display. But now it looks like that's no longer the case.