Importing Pyomo module causes high VSCode Code Helper CPU usage

[irm-codebase]

Type: Bug

Behaviour

Expected vs. Actual

Importing the pyomo library (used for optimisation modelling) should not cause any issues with VSCode.

However, if you import it as:

import pyomo.environ as pyo

Code Helper will jump to 99% CPU usage and syntax coloring in VSCode will stop working (i.e., variables are no longer detected/colored in the editor).

I have noticed that this occurs mostly in files with high amounts of usage of the 'pyo' instance, and when it is present in function annotations.

Steps to reproduce:

1. Create a python file with high pyomo usage, keeping the pyomo import commented.
2. Pylance/Python extension works fine.
3. Uncomment the import and reload VSCode.
4. Failure, Code Helper goes crazy.

I am using Mac with an Intel chipset.
The code below is an excerpt of my file (cannot fully share it). I assume copy-pasting the functions several times with different names should trigger the issue.

import pandas as pd
import numpy as np
# import pyomo.environ as pyo
import gen_utils.k_clustering as k_means

def cnf_model_parameters(mod: pyo.ConcreteModel, country_df: pd.DataFrame):
    """Set parameters used throughout the model.

    Requirements: generic indexes.

    Args:
        mod (pyo.ConcreteModel): pyomo model
        country_df (pd.DataFrame): dataframe with country parameters
    """
    # Obtain yearly discount factors TODO: this should be in a generic parameter function
    y_0 = mod.Years.first()
    dr_uniform = country_df.loc["Discount_rate_uniform"].loc[y_0, "Value"]
    mod.p_DR = pyo.Param(initialize=dr_uniform)

    def param_discount_factor(mod, year):
        return 1 / np.power(1 + mod.p_DR, (year - mod.Years.first()))

    mod.p_DiscFactors = pyo.Param(mod.Years, initialize=param_discount_factor, doc="Discount Factors")


def cnf_model_variables(mod: pyo.ConcreteModel):
    """Create the pyomo variables used.

    Args:
        mod (pyo.ConcreteModel): pyomo model to configure.
    """
    # Generator power output [GW]h
    mod.p = pyo.Var(mod.DxpTechs, mod.Years, mod.DxpDays, mod.DxpHours, domain=pyo.NonNegativeReals)
    # Generator installed capacity [GW]
    mod.p_nom = pyo.Var(mod.DxpTechs, mod.Years, domain=pyo.NonNegativeReals)
    # Generator newly installed capacity [GW]
    mod.p_nom_new = pyo.Var(mod.DxpTechs, mod.Years, domain=pyo.NonNegativeReals)
    # Generator closed capacity [GW]
    mod.p_nom_closed = pyo.Var(mod.DxpTechs, mod.Years, domain=pyo.NonNegativeReals)

    # Import / Export power output
    mod.imp_p = pyo.Var(["Import"], mod.Years, mod.DxpDays, mod.DxpHours, domain=pyo.NonNegativeReals)
    mod.exp_p = pyo.Var(["Export"], mod.Years, mod.DxpDays, mod.DxpHours, domain=pyo.NonNegativeReals)
    # Import / Export installed capacity [GW]
    mod.imp_p_nom = pyo.Var(["Import"], mod.Years, domain=pyo.NonNegativeReals)
    mod.exp_p_nom = pyo.Var(["Export"], mod.Years, domain=pyo.NonNegativeReals)

    # Import / Export newly installed capacity [GW]
    mod.line_p_nom_new = pyo.Var(["Line"], mod.Years, domain=pyo.NonNegativeReals)
    # Pseudo-line power flow [GW]h
    mod.line_p = pyo.Var(["Line"], mod.Years, mod.DxpDays, mod.DxpHours, domain=pyo.Reals)
    # Pseudo-line installed capacity [GW]h
    mod.line_p_nom = pyo.Var(["Line"], mod.Years, domain=pyo.NonNegativeReals)

Diagnostic data

• Python version (Miniconda): 3.10.8
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Conda
• Value of the python.languageServer setting: Default

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

User Settings

languageServer: "Pylance"

Extension version: 2022.20.2
VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T17:07:18.579Z)
OS version: Darwin x64 21.6.0
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz (8 x 2300)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	5, 6, 4
Memory (System)	16.00GB (0.93GB free)
Process Argv	--crash-reporter-id 7078e789-9013-4471-871d-05fa2bc9d050
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
vscccc:30610679
pyindex848:30577860
nodejswelcome1cf:30587006
2e4cg342:30602488
89544117:30613380
fim-prod:30623723

[irm-codebase]

Some added notes:

• Stopping the stuck Code Helper process fixes syntax highlights, and code suggestions still work.
• Importing and using any Pyomo functionality seems to trigger the issue (initially, I thought it was only due to function annotations).
• It also happens in Jupyter.

[fleimgruber]

I am also seeing 99% CPU usage, though not the syntax coloring behavior. Also on Python 3.10.8, Conda and using Pyomo.

[erictraut]

Transferring to pyright, since this is a core type checker issue.

[irm-codebase]

@fleimgruber, in my case, it seems reasonably repeatable.
For example:

Here, Pyomo is commented out, and colouring works fine.

If I enable the import, only pyomo's colouring does not work.

Then, I close then re-open VSCode while keeping pyomo's import active...
The colouring is gone for the whole file.

I've noticed that the Code Helper goes extra crazy on CPU usage in the last case too.

[fleimgruber]

@irm-codebase Thanks for checking back! I am using a custom color highlighting where the differences were not immediately apparent (i.e. parts worked fine). With one of the default themes I can confirm and reproduce the behavior you see with your steps and Ctrl-Shift-P then "Developer: Reload Window".

[erictraut]

I'm able to repro the problem and will investigate further. Pyright is attempting to infer a function return type in the pyomo library (which does not contain any type annotations), and it's choking on one of the functions.

[erictraut]

This will be addressed in the next release of pyright and a future release of pylance.

[erictraut]

This is included in pyright 1.1.291, which I just published. It will also be included in a future release of pylance.

[irm-codebase]

Fantastic! Thank you, @erictraut.
Is there an estimate on when Pylance will integrate the fix?
I assume installing Pylance and Pyright simultaneously might lead to weird behaviour.

[erictraut]

Pyright is typically published on Tuesday each week, and Pylance is published on Wednesday. Two versions of Pylance are published each week — a production version and an "insiders build". The latter includes changes from Tuesday's pyright build. The former contains pyright changes from the previous week. In other words, the production version lags the insiders version by one week. So, if you switch to the Pylance "insiders build", you will see this change within the next 24 hours.

And yes, pylance and pyright will not run at the same time. The pyright VS Code extension disables itself if it sees that Pylance is installed.