fix: High CPU usage while going to the symbol definition

clients/vscode-hlasmplugin/CHANGELOG.md

@@ -7,6 +7,7 @@
 #### Fixed
 - Operands no longer classified as remarks when instruction or macro is not recognized
 - New or changed files are parsed only when they are opened in the editor
+- High CPU usage while going to the symbol definition
 
 ## [1.7.0](https://github.com/eclipse/che-che4z-lsp-for-hlasm/compare/1.6.0...1.7.0) (2023-03-08)
 

clients/vscode-hlasmplugin/src/extension.ts

@@ -30,6 +30,7 @@ import { blockCommentCommand, CommentOption, lineCommentCommand } from './commen
 import { HLASMCodeActionsProvider } from './hlasmCodeActionsProvider';
 import { hlasmplugin_folder } from './constants';
 import { ConfigurationsHandler } from './configurationsHandler';
+import { getLanguageClientMiddleware } from './languageClientMiddleware';
 
 export const EXTENSION_ID = "broadcommfd.hlasm-language-support";
 
@@ -80,7 +81,8 @@ export async function activate(context: vscode.ExtensionContext) {
                 vscode.workspace.createFileSystemWatcher(hlasmplugin_folder + '/*.json'),
             ]
         },
-        errorHandler: clientErrorHandler
+        errorHandler: clientErrorHandler,
+        middleware: getLanguageClientMiddleware(),
     };
 
 

clients/vscode-hlasmplugin/src/languageClientMiddleware.ts

@@ -0,0 +1,73 @@
+/*
+ * Copyright (c) 2023 Broadcom.
+ * The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
+ *
+ * This program and the accompanying materials are made
+ * available under the terms of the Eclipse Public License 2.0
+ * which is available at https://www.eclipse.org/legal/epl-2.0/
+ *
+ * SPDX-License-Identifier: EPL-2.0
+ *
+ * Contributors:
+ *   Broadcom, Inc. - initial API and implementation
+ */
+
+import { Middleware } from 'vscode-languageclient';
+
+export function getLanguageClientMiddleware(): Middleware {
+    // VSCode generates flood of didOpen/didClose event when trying to go to a symbol definition using mouse (CTRL+point).
+    // This behavior is documented (and apprently work on) but it causes meaningless activity in the language server.
+
+    // The purpose of the middleware is to delay sending the didOpen event by a fraction of a second
+    // and attempt to pair it with didClose generated almost immediatelly after.
+    // In that case, we drop both events.
+
+    const pendingOpens = new Map<string, {
+        send: () => void,
+        clearTimeout: () => void,
+    }>();
+    const timeout = 50;
+
+    return {
+        didOpen: (data, next) => {
+            const uri = data.uri.toString();
+
+            const didOpenEvent = pendingOpens.get(uri);
+            if (didOpenEvent) {
+                console.error('Double open detected for', uri);
+                pendingOpens.delete(uri);
+                didOpenEvent.clearTimeout();
+                didOpenEvent.send();
+            }
+
+            const timerId = setTimeout(() => {
+                pendingOpens.delete(uri);
+                next(data);
+            }, timeout);
+            pendingOpens.set(uri, {
+                send: () => { next(data); },
+                clearTimeout: () => { clearTimeout(timerId); },
+            });
+        },
+        didChange: (data, next) => {
+            const uri = data.document.uri.toString();
+            const didOpenEvent = pendingOpens.get(uri);
+            if (didOpenEvent) {
+                pendingOpens.delete(uri);
+                didOpenEvent.clearTimeout();
+                didOpenEvent.send();
+            }
+            next(data);
+        },
+        didClose: (data, next) => {
+            const uri = data.uri.toString();
+            const didOpenEvent = pendingOpens.get(uri);
+            if (didOpenEvent) {
+                pendingOpens.delete(uri);
+                didOpenEvent.clearTimeout();
+            }
+            else
+                next(data);
+        },
+    };
+}