Performance Improvements using Worker Threads

I've been looking into a performance issue related to opening notebook.
TLDR - Opening a notebook in widows for Chris Dias and me takes 20-30 seconds (Jupyter extension is not doing anything).
If we disable the Python extension, it opens almost immediately (~5 seconds).

I think the delay is in Python extension spawning n processes. I know we're making changes to environment discovery.
However I think we can improve this even further (or, even with the current changes, it might not be sufficient).

I believe the problem lies with the spawning of processes, if we spawn proceses, it takes a few ms to just spawn the process, e.g. i know on Windows, spawning a conda process takes a few seconds, & that's blocking (spawning processes in node is synchronous) - but communication is async.

This blocks the main thread, hence blocks all other extensions (kinda explains why it takes so many seconds to just open a notebook when Jupyter isn't doing anything).

Suggestion - Why not spawn the processes in a worker thread (completely non-blocking)
I did look into this last year, & we can do this today.

What can we move to these worker threads:
Spawning processes just to get their environment information
Spawning processes to run code e.g. python -c "import ipykernel"
& other simple processes

Don Jayamanne (@DonJayamanne)

Don Jayamanne (@DonJayamanne) we should turn this into a meta issue an create work items for each particular case we move into worker. This is great if we can do this where ever possible.

FYI - We have managed to resolve the performance issue in Jupyter notebooks by delaying the loading of the Python extension. Now Jupyter Notebooks open in around 3 seconds, basically the Python extension gets loaded/activated AFTER the notebook is opened.
Hence this isn't a priority anymore, but if we had this, we'd ensure the Jupyter extension doesn't regress & we don't need to worry about other extensions blocking us. (or this extenison not blocking others)

Spike: Investigate using webworker for Python discovery #21755

Looking briefly at how the locators work I believe you could make this much faster if you performed this and other similar functions in parallel:

vscode-python/src/client/pythonEnvironments/base/locators/common/resourceBasedLocator.ts

Lines 46 to 63 in 203f58b

    
           public async *iterEnvs(query?: PythonLocatorQuery): IPythonEnvsIterator<BasicEnvInfo> { 
        
               await this.activate(); 
        
               const iterator = this.doIterEnvs(query); 
        
               if (query?.envPath) { 
        
                   let result = await iterator.next(); 
        
                   while (!result.done) { 
        
                       const currEnv = result.value; 
        
                       const { path } = getEnvPath(currEnv.executablePath, currEnv.envPath); 
        
                       if (arePathsSame(path, query.envPath)) { 
        
                           yield currEnv; 
        
                           break; 
        
                       } 
        
                       result = await iterator.next(); 
        
                   } 
        
               } else { 
        
                   yield* iterator; 
        
               } 
        
           }

I may just not be understanding things but from what I hear, environment discovery can take 20 seconds which seems like an outrageous amount of time to me. Have we done a perf trace to see where time is actually being spent when the environment activation is happening?

I believe the problem lies with the spawning of processes, if we spawn proceses, it takes a few ms to just spawn the process, e.g. i know on Windows, spawning a conda process takes a few seconds, & that's blocking (spawning processes in node is synchronous) - but communication is async.

Processes should block main for milliseconds, spawning a single conda process certainly should not be blocking the extension host for seconds.

Processes should block main for milliseconds, spawning a single conda process certainly should not be blocking the extension host for seconds.

yes that’s correct
conda takes 20 seconds but that doesn’t block node, I should have been more clear
I found using worker threads to be an improvement, at least that’s when I prototyped the code

Kartik Raj (@karrtikr)

I had a chat with Kartik Raj (@karrtikr) yesterday and it looks like there's some pretty nice gains to be made by making locators run more in parallel.

Closing in favor of #22146 (comment).

Navigation Menu

Repository navigation

Performance Improvements using Worker Threads #15813

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	public async *iterEnvs(query?: PythonLocatorQuery): IPythonEnvsIterator<BasicEnvInfo> {
	await this.activate();
	const iterator = this.doIterEnvs(query);
	if (query?.envPath) {
	let result = await iterator.next();
	while (!result.done) {
	const currEnv = result.value;
	const { path } = getEnvPath(currEnv.executablePath, currEnv.envPath);
	if (arePathsSame(path, query.envPath)) {
	yield currEnv;
	break;
	}
	result = await iterator.next();
	}
	} else {
	yield* iterator;
	}
	}

Performance Improvements using Worker Threads #15813

Description

Activity

karthiknadig commented on Mar 30, 2021

DonJayamanne commented on Apr 2, 2021

karrtikr commented on Aug 4, 2023

Tyriar commented on Sep 15, 2023

DonJayamanne commented on Sep 16, 2023

Tyriar commented on Sep 16, 2023

karrtikr commented on Nov 15, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions