The publisher log display is implemented within extensions/vscode/src/views/logs.ts. It's approach for displaying the log messages as they are received is very inefficient and should be refactored.
This code performs repetitive, mostly redundant object construction. As log messages are received, they are appended into an array of other log messages within the stages object, with then the code signalling for a refresh. VSCode then calls GetChildren, which causes every stage and every one of the log messages for each stage to be constructed over and over again.
This reconstruction of the entire set of TreeItems occurs once for every log message received, plus a couple for the stable stages. In my testing for deployment of the fastapi-simple, this occurred 720 times.
I would suggest the code create each TreeItem once, and simply keep passing references back into the VSCode callbacks for getChildren. This would eliminate the redundant construction of objects, which is currently occurring.
The publisher log display is implemented within
extensions/vscode/src/views/logs.ts. It's approach for displaying the log messages as they are received is very inefficient and should be refactored.This code performs repetitive, mostly redundant object construction. As log messages are received, they are appended into an array of other log messages within the stages object, with then the code signalling for a refresh. VSCode then calls GetChildren, which causes every stage and every one of the log messages for each stage to be constructed over and over again.
This reconstruction of the entire set of TreeItems occurs once for every log message received, plus a couple for the stable stages. In my testing for deployment of the
fastapi-simple, this occurred 720 times.I would suggest the code create each TreeItem once, and simply keep passing references back into the VSCode callbacks for getChildren. This would eliminate the redundant construction of objects, which is currently occurring.