Initialize tooling api even more lazily when open toolbars

[Doug Ayers]

Upon opening IntelliJ, the first time in an IlluminatedCloud project where I try to open a toolbar like Log Viewer, SOQL Query, or Anonymous Apex, then I'm promtped with a modal dialog telling me that IC is "initialing tooling api" or "retrieving log levels".

In my experience, this can take 10 or more seconds per toolbar the first time it's opened during a coding session. Although in the grand scheme of things, that's not a long time, but for me it feels like an abrupt jolt to what I'm trying to get done.

Would it be possible for those loading behaviors to occur in the background, or be provided option to tell those modal dialogs to move to the background, so that I could immediately begin writing my SOQL query or anonymous Apex and then only if the loading has not finished by the time I execute the query or code, then I'm presented with the modal?

Example scenario:

Assume it takes 10 seconds for the anonymous apex toolbar to initialize the tooling api for first use. If it takes me 15 seconds to actual write my code before I click execute then I would never be shown the modal wait screen. If it takes me 7 seconds to write my code before I click execute, then I would be shown the modal wait screen for a couple seconds. Either way, it would reduce the amount of time or chances that I would ever be shown the modal screen.

[Scott Wells]

Yeah, the issue is actually the Apache CXF-based SOAP API client that's based on Salesforce's published WSDLs for the various APIs. The Tooling API WSDL has gotten HUGE which results in a respectively HUGE number of XML-bound classes in that namespace. When CXF first initializes each SOAP client, it has to load and scan the annotations on all of these classes. That's where all of this time goes, and it's also why it's a one-time cost. I've tuned CXF as much as possible based on the available options. The only other available options to speed this up are to stop using CXF (a massive change to IC overall) or to try to extract the relevant subset of classes from all of those generated by WSDL-to-Java to create a smaller footprint SOAP client. I've been thinking about trying to do the latter as IC probably only uses a small subset of the actual Tooling API to do what it does...same with the Metadata API which is the second worst offender in this regard.

I'll keep this issue open to track progress on that effort.

[Doug Ayers]

Thanks for the follow up and insight, Scott.

[Scott Wells]

Okay, I actually made significant progress on this during flights and in between sessions last week at DF18. Here's a test build that trims down all of the WSDLs to exactly what IC needs for its specific API calls. You can install it using Settings/Preferences>Plugins>Install plugin from disk.

I'm making it available as a test build first because while it's been working great for me for the past week, I know that it's possible that it might be affected by org shape. I'd like to get some additional data points against various types of orgs before releasing this into the wild.

Please let me know if you've installed this whether it's working fine for you (and delivering on the promise of a faster API client initialization the first time after starting the IDE process) or if it's causing issues.

[Scott Wells]

New build based on 2.0.3.8 with Winter '19/API v44.0 updates.

[Doug Ayers]

Thanks, Scott! I just tested loading up the Logs and Apex toolbars tonight and it was near instant. Thanks for the updates!

[Scott Wells]

Glad to hear it's working well for you, Doug, but it hasn't been officially released yet. I'll likely do so on Monday, so reopening for now.

[Scott Wells]

Delivered in 2.0.4.0. Please let me know ASAP if you have any issues after taking this build with the SOAP API calls to Salesforce.

[Scott Wells]

Delivered in 1.8.4.0 for Illuminated Cloud 1.