For the sake of profiling ASGI apps, it would be really helpful if there was a way to make use of python 3.7's contextvars while filtering via yappi.get_func_stats. If yappi supported this, you could get per-request-response-cycle profiling through an ASGI middleware.

I'm not sure if the necessary functionality already exists or not, but wanted to open an issue in case anyone else has thought about this, or in case someone is aware of an existing way to accomplish this.

See https://github.com/tiangolo/fastapi/issues/701 for more context on how we'd like to use this.

Proposal to make yappi grok greenlets

This PR is a proposal to make yappi understand greenlets. The change allows yappi to map each greenlet to a unique execution context. Further, it also adjusts CPU stats measured to account for interleaving greenlet execution on one thread.

Changes required

The following changes are required by the fix:

• ensure _profile_thread is called only from the target thread to be profiled.

  _profile_thread invokes the _current_context_id operation which retrieves the execution context of a thread.

  Using _current_context_id to retrieve the context information from another thread is not guaranteed to work and is hard to get right when yappi is configured with set_context_id_callback because the callback is not passed the information about what thread it has to fetch information for.

  It is also to hard to achieve the above when using greenlets because there is no obvious way to retrieve the greenlet currently executing on another thread. i.e there is no simple way to retrieve the greenlet currently executing on threadA from threadB.

  To get around this, this change guarantees that _profile_thread and _ensure_thread_profiled is only called from the target thread by removing their invocations from the 'start' sequence when 'multithreading' is enabled and delaying it. This is done by attaching a separate profiler func callback (profile_event and profile_event_c) to the threads. These functions first run _ensure_thread_profiled in the target thread context and change the profiler func callback to _yapp_callback. This way the work done by the start sequence is reduced and _ensure_thread_profiled is delayed to the first time a callback is invoked on the target thread.

• add set_ctx_backend and allow specifying threading backend as greenlets as suggested by @sumerc

• modify _current_context_id to identify the greenlet currently being executed when backend is greenlets. This is done the same way as it is for threads, except here we use the dictionary of the greenlet rather than that of the thread.

• account for interleaving greenlet executions on the same native thread

  greenlet is a co-operative multitasking framework that introduces user controlled threads called greenlets. Each native python thread can run a number of greenlets. Greenlets on the same thread co-operatively switch between one another using greenlet.switch. it is important to note that a greenlet can only execute on the thread it was spawned on. As a result, greenlets spawned on one thread can only switch between each other.

  Greenlets do not play well with yappi. Yappi uses thread local stats to track the CPU usage of each frame. It tracks the usage at the entry of each function and at the exit of each function and subtracts the values to get the total clock cycles spent in that frame. This does not work well with greenlets. Let's take an example of two greenlets A and B and view the following sequence of events.

  • greenletA is currently running
  • greenletA enters function foo
  • greenletA co-operatively switches to greenletB
  • greenletB consumes 1 second of CPU
  • greenletB switches over back to greenletA
  • greenletA exits function foo

  The CPU usage of function foo will be 1 second more than it should be because greenletB's execution is interleaved.

  To account for this we have to track the context switches and adjust stats. The solution implemented in this change is a derivative of https://github.com/ajdavis/GreenletProfiler with some modifications to account for multiple native threads

  To track context switches:

  • declare a new thread local variable tl_prev_ctx. This needs to be thread local since multiple threads can exist. Greenlet context switches should be tracked at a thread level rather than at a global level.
  • tl_prev_ctx is initialised in _ensure_thread_profiled. It is initialised to the greenlet currently running on that thread
  • use tl_prev_ctx in _yapp_callback to determine if the context changed since the last time it was set.

  To adjust stats, if a switch is noticed from prev->current, then:

  • pause prev. Store the time it was paused under the paused_at field of the context associated with prev
  • resume the current greenlet. use the paused_at field and the current value of tickcount to determine how long the greenlet was paused for. Since a greenlet can only execute on one thread, subtracting these values is an accurate measure.

NOTE: Another way to track context switches is by using greenlet.settrace (see https://greenlet.readthedocs.io/en/latest/). However installing this trace function for each native thread and uninstalling it did not seem easy to implement.

What is remaining?

This is not a complete fix, here's what is remaining:

• make this work for wall clock time or document limitations of wall clock time measurement
• make declaration of tl_prev_ctx platform independent. __thread is not portable to windows AFAIK
• fix build system to install greenlet before compilation of yappi C extension. greenlet.h is required by yappi.
• enumerate and add more test cases
• there are a few TODOs added within the code. They are to be complete before closing. Some of them require discussion with @sumerc for a better understanding.

Tests performed

• The tests provided under https://github.com/sumerc/yappi/pull/53 have been modified to test correct CPU usage measurement
• The script provided by @sumerc under https://github.com/sumerc/yappi/pull/53 was run. Here are the results:

import gevent
import yappi

def burn_cpu(sec):
    t0 = yappi.get_clock_time()
    elapsed = 0
    while (elapsed < sec):
        for _ in range(1000):
            pass
        elapsed = yappi.get_clock_time() - t0


def foo():
    burn_cpu(0.1)
    gevent.sleep(1.0)


def bar():
    burn_cpu(0.1)
    gevent.sleep(1.0)


#yappi.set_clock_type("wall")
yappi.set_ctx_backend("greenlet")
yappi.start()
g1 = gevent.spawn(foo)
g2 = gevent.spawn(bar)
gevent.wait([g1, g2])

yappi.stop()
yappi.get_func_stats(
    filter_callback=lambda x: yappi.func_matches(x, [foo, bar])
).print_all()

Clock type: CPU
Ordered by: totaltime, desc

name                                  ncall  tsub      ttot      tavg
rand_test.py:19 bar                   1      0.000032  0.100202  0.100202
rand_test.py:14 foo                   1      0.000040  0.100171  0.100171

• automated tests were executed with both python2.7 and python3.8

As part of an application profiler plugin project for the ASGI protocol, where users can just pass a list of functions to profile, I was using a simple yappi.get_func_stats({"name": somefunction.__qualname__, "tag": ctx_tag}) filter, thinking it would be enough to unambigously select those functions. I later found out that __qualname__ is only unambiguous within the scope of a module, so I should in all likelyhood specify somefunction.__module__ as part of the filter as well, but that got me to look at the code yappi uses to identify the functions being called:

https://github.com/sumerc/yappi/blob/6c97f55ae69a0979bdea8e557510a5d349da340c/yappi/_yappi.c#L546-L567

It uses ml_name as the function name, which apparently corresponds to __name__, not __qualname__ like I initially figured yappi would use, and has a few edge-cases for both function and module name that could make it difficult/unreliable to build the correct filter automatically.

Shouldn't yappi have some kind of filter_from_function_descriptor function to generate a detailled filter from a function descriptor automatically, instead of leaving users guessing as to whether they're accidentally profiling other functions with the same name as the one they want?

Coroutines being run via asyncio.gather do not show-up in the callgraph for the calling function.

asyncio.gather returns a Future gathering the results from the provided coroutines. Timings are correct (up to the caveats in #21) but the callgraph only shows the creation of the gathering future. The caller for the coroutines run via gather is the event loop.

Is there any way to provide hints to yappi to change the caller for the coroutines?

Example:

from asyncio import gather,  run, sleep
import yappi

async def aio_worker(id):
    await sleep(1.)
    return id

async def doit():
    task1 = aio_worker(1)
    task2 = aio_worker(2)

    return await gather(task1, task2)

if __name__ == '__main__':
    yappi.set_clock_type('wall')
    with yappi.run(builtins=True):
        run(doit())

    stats = yappi.get_func_stats()

    print("\n\nCallers of 'aio_worker'")
    ps = yappi.convert2pstats(stats)
    ps.print_callees('doit')
    ps.print_callees('gather')  # <- this schedules a future collecting results, only see its __init__ in callees

    ps.print_callers('aio_worker')  # <- only caller is the event loop: "__builtin__:0(<method 'run' of 'Context' objects>)"

For me it would be ok if gather would not show-up in the callgraph at all and aio_worker looked like a direct callee of doit.

First of all, thanks a lot for this project, yappi is really the best Python profiler !

In my projects I use gevent extensively. I was full of hope when I found this blog article:

https://emptysqua.re/blog/greenletprofiler/

Someone made a greenlet profiler a few years ago on top of yappi...

But the project is Python 2, and it was coming with a modified, bundled version of yappi.

Now that yappi supports coroutines (with asyncio, unfortunately), could you please give me some guidance how to redo what was done with greenletprofiler ?

I would be happy to contribute to yappi with gevent support, but I need some help - my C++ skills are rusty and I don't know the code.

I saw in this discussion https://github.com/sumerc/yappi/issues/21 that it was something you thought about once... But I am afraid set_ctx_backend() was finally not implemented ?

Thanks a lot

I'm not really sure how you want to handle the fact that this requires python 3.7.

Figured I'd open this to share; feel free to scavenge it into the coroutine-profiling branch in your own way, or to provide me with some guidance about how you'd like it refactored. (No pressure to merge this PR now or ever, but I'm happy to add more if desired.)

Also, let me know if there are additional tests you'd like me to add.

I noticed this when trying to use yappi with tornado. Here is a simple repro:

import yappi
yappi.start()


def test_mem():
    buf = bytearray()
    buf += b't' * 200
    view = memoryview(buf)[10:].tobytes()
    del buf[:10]
    return view


if __name__ == "__main__":
    test_mem()

Without yappi, the code completes successfully. With yappi I get the following error:

Traceback (most recent call last):
  File "yappi_repro.py", line 14, in <module>
    test_mem()
  File "yappi_repro.py", line 9, in test_mem
    del buf[:10]
BufferError: Existing exports of data: object cannot be re-sized

Reproducible on python 3.6, 3.7 and 3.8. I have not tried python 2.7

Any ideas how to fix this?

I first got an error saying to install Microsoft Visual Studio C++ 14.0 or later build tools. I installed them from https://visualstudio.microsoft.com/visual-cpp-build-tools/

Here is the checkbox I ticked for the build tools. Which version of MSVC does yappi require?

❯ pip install yappi --no-cache-dir
Collecting yappi
  Downloading yappi-1.3.2.tar.gz (58 kB)
     |████████████████████████████████| 58 kB 2.0 MB/s
Building wheels for collected packages: yappi
  Building wheel for yappi (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: 'c:\tools\miniconda3\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Use
rs\\jaan\\AppData\\Local\\Temp\\pip-install-930ozymw\\yappi_e32707e233e74c018e9d5f8a6d367185\\setup.py'"'"'; __file__='"
'"'C:\\Users\\jaan\\AppData\\Local\\Temp\\pip-install-930ozymw\\yappi_e32707e233e74c018e9d5f8a6d367185\\setup.py'"'"';f 
= getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools im
port setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '
"'"'exec'"'"'))' bdist_wheel -d 'C:\Users\jaan\AppData\Local\Temp\pip-wheel-6lwb2tps'
       cwd: C:\Users\jaan\AppData\Local\Temp\pip-install-930ozymw\yappi_e32707e233e74c018e9d5f8a6d367185 
  Complete output (15 lines):
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build\lib.win32-3.8
  copying yappi\yappi.py -> build\lib.win32-3.8
  running build_ext
  building '_yappi' extension
  creating build\temp.win32-3.8
  creating build\temp.win32-3.8\Release
  creating build\temp.win32-3.8\Release\yappi
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29910\bin\HostX86\x86\cl.exe /c /no
logo /Ox /W3 /GL /DNDEBUG /MD -Ic:\tools\miniconda3\include -Ic:\tools\miniconda3\include "-IC:\Program Files (x86)\Micr
osoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29910\include" /Tcyappi/_yappi.c /Fobuild\temp.win32-3.8\Release
\yappi/_yappi.obj
  _yappi.c
  c:\tools\miniconda3\include\pyconfig.h(59): fatal error C1083: Cannot open include file: 'io.h': No such file or direc
tory
  error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.28.29910\\bin\
\HostX86\\x86\\cl.exe' failed with exit status 2
  ----------------------------------------
  ERROR: Failed building wheel for yappi
  Running setup.py clean for yappi
Failed to build yappi
Installing collected packages: yappi
    Running setup.py install for yappi ... error
    ERROR: Command errored out with exit status 1:
     command: 'c:\tools\miniconda3\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\U
sers\\jaan\\AppData\\Local\\Temp\\pip-install-930ozymw\\yappi_e32707e233e74c018e9d5f8a6d367185\\setup.py'"'"'; __file__=
'"'"'C:\\Users\\jaan\\AppData\\Local\\Temp\\pip-install-930ozymw\\yappi_e32707e233e74c018e9d5f8a6d367185\\setup.py'"'"';
f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools
import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__,
 '"'"'exec'"'"'))' install --record 'C:\Users\jaan\AppData\Local\Temp\pip-record-wf2xdwwh\install-record.txt' --single-v
ersion-externally-managed --compile --install-headers 'c:\tools\miniconda3\Include\yappi'
         cwd: C:\Users\jaan\AppData\Local\Temp\pip-install-930ozymw\yappi_e32707e233e74c018e9d5f8a6d367185\
    Complete output (15 lines):
    running install
    running build
    running build_py
    creating build
    creating build\lib.win32-3.8
    copying yappi\yappi.py -> build\lib.win32-3.8
    running build_ext
    building '_yappi' extension
    creating build\temp.win32-3.8
    creating build\temp.win32-3.8\Release
    creating build\temp.win32-3.8\Release\yappi
    C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29910\bin\HostX86\x86\cl.exe /c /
nologo /Ox /W3 /GL /DNDEBUG /MD -Ic:\tools\miniconda3\include -Ic:\tools\miniconda3\include "-IC:\Program Files (x86)\Mi
crosoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29910\include" /Tcyappi/_yappi.c /Fobuild\temp.win32-3.8\Relea
se\yappi/_yappi.obj
    _yappi.c
    c:\tools\miniconda3\include\pyconfig.h(59): fatal error C1083: Cannot open include file: 'io.h': No such file or dir
ectory
    error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.28.29910\\bi
n\\HostX86\\x86\\cl.exe' failed with exit status 2
    ----------------------------------------
ERROR: Command errored out with exit status 1: 'c:\tools\miniconda3\python.exe' -u -c 'import io, os, sys, setuptools, t
okenize; sys.argv[0] = '"'"'C:\\Users\\jaan\\AppData\\Local\\Temp\\pip-install-930ozymw\\yappi_e32707e233e74c018e9d5f8a6
d367185\\setup.py'"'"'; __file__='"'"'C:\\Users\\jaan\\AppData\\Local\\Temp\\pip-install-930ozymw\\yappi_e32707e233e74c0
18e9d5f8a6d367185\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else
io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.clo
se();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\jaan\AppData\Local\Temp\pip-record-wf2xdw
wh\install-record.txt' --single-version-externally-managed --compile --install-headers 'c:\tools\miniconda3\Include\yapp
i' Check the logs for full command output.

> pip install yappi Collecting yappi Using cached https://files.pythonhosted.org/packages/37/dc/86bbe1822cdc6dbf46c644061bd24217f6a0f056f00162a3697c9bea7575/yappi-1.2.3.tar.gz Installing collected packages: yappi Running setup.py install for yappi ... error ERROR: Command errored out with exit status 1: command: 'c:\users\rabbott\appdata\local\programs\python\python38-32\python.exe\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\Users\rabbott\AppData\Local\Temp\pip-install-q4kk7o84\yappi\setup.py'"'"'; file='"'"'C:\Users\rabbott\AppData\Local\Temp\pip-install-q4kk7o84\yappi\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record 'C:\Users\rabbott\AppData\Local\Temp\pip-record-yukv2gvu\install-record.txt' --single-version-externally-managed --compile cwd: C:\Users\rabbott\AppData\Local\Temp\pip-install-q4kk7o84\yappi
Complete output (9 lines): running install running build running build_py creating build creating build\lib.win32-3.8 copying yappi\yappi.py -> build\lib.win32-3.8 running build_ext building '_yappi' extension error: Microsoft Visual C++ 14.0 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/ ---------------------------------------- ERROR: Command errored out with exit status 1: 'c:\users\rabbott\appdata\local\programs\python\python38-32\python.exe\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\Users\rabbott\AppData\Local\Temp\pip-install-q4kk7o84\yappi\setup.py'"'"'; file='"'"'C:\Users\rabbott\AppData\Local\Temp\pip-install-q4kk7o84\yappi\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record 'C:\Users\rabbott\AppData\Local\Temp\pip-record-yukv2gvu\install-record.txt' --single-version-externally-managed --compile Check the logs for full command output.

Good day,

I'm author of pptop, which has a plugin for yappi profiler. After updating to 1.2.1, Yappi prints a lot of "Internal Error 15" messages when working. I believe the issue is because pptop plugin starts yappi from the own thread, however everything seems to work fine except this message.

p.s. it would be also nice to have an ability obtaining data fields from get_func_stats() by keywords, as I see some of their indexes are changed from version to version.

Hi there,

It would be lovely to filter stats by package. Because you're using PyObject_RichCompareBool as part of the filter it's already possible to achieve this with a helper object. Would you be interested in integrating this as a feature with a stable API?

My current implementation is:

import dataclasses
import importlib
import os

@dataclasses.dataclass
class PackageModule:
    package: str
    
    def __post_init__(self):
        mod = importlib.import_module(self.package)
        self.fn = mod.__file__
        if self.fn.endswith("__init__.py"):
            self.fn = os.path.dirname(self.fn)
    
    def __eq__(self, other):
        return other.startswith(self.fn)
        

yappi.get_func_stats(filter={"modname": PackageModule("apd.aggregation")}).print_all()

There are caveats to this, mainly that it requires the module to be importable, and not undesirable to import (such as potential import-time side-effects), but I think it improves the usability a fair bit.

What do you think? If you're interested I'm happy to put together a PR.

Matt

Bumps pypa/cibuildwheel from 2.9.0 to 2.11.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps pypa/gh-action-pypi-publish from 1.5.1 to 1.6.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dear Yappies, thanks for this fantastic tool - I wish I would have found it earlier :-)

This ticket is about an issue with names derived for bass classes in a simple class hierarchy. It seems that base class methods are given the name of the first child class which calls it, and that subsequent usages by other child classes then get accounted incorrectly.

Here is a small reproducer:

#!/usr/bin/env python3

from test_yappi import Base

class A(Base):
    def __init__(self):
        self.sleep(1)

class B(Base):
    def __init__(self):
        self.sleep(1)

def main():
    _ = A()
    for _ in range(10):
        _ = B()

if __name__ == '__main__':

    import yappi
    yappi.start(builtins=False)

    main()

    yappi.get_thread_stats().print_all()
    stats = yappi.convert2pstats(yappi.get_func_stats())
    stats.print_stats()
    stats.dump_stats('pstats.prof')

import time

class Base(object):

    def sleep(self, tout):
        time.sleep(tout)

test_yappi/__init__.py exists but is empty.

With this code I would expect to find A.sleep and B.sleep, or to find Base.sleep as profiled methods, but in fact I find only A.sleep:

$ strings pstats.prof | grep sleep
A.sleep)

and the stats result then reflect that:

$ ./test_yappi.py 

name           id     tid              ttot      scnt        
_MainThread    0      140335337744192  0.001044  1         
         23 function calls in 0.000 seconds

   Random listing order was used

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.001    0.001 ./test_yappi.py:13(main)
       11    0.000    0.000    0.001    0.000 [...]/test_yappi/base.py:6(A.sleep)
       10    0.000    0.000    0.001    0.000 ./test_yappi.py:10(B.__init__)
        1    0.000    0.000    0.000    0.000 ./test_yappi.py:6(A.__init__)

(BTW: I would have expected different values for cumtime, about 11 seconds for main - what happened?)

When attempting to evaluate results it is basically impossible to separate what contributions the sleep calls for A and B have, respectively. In this specific case it helps a bit to plot the results, but in any non-trivial use case that becomes unwieldy very fast:

Is this known behavior? Is there a way to avoid the mis-labeling?

Thanks, Andre.

Bumps pypa/cibuildwheel from 2.9.0 to 2.10.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Currently gevent tests are excluded for 3.11 as it is not compiling on 3.11 yet

from https://github.com/sumerc/yappi/pull/107

Include them once gevent released on 3.11.

Hi i'm having some problems trying to install yappi on windows 10 (x32) my python version is 3.11 , i belive the problem is version related:

Here the callstack:

  │ exit code: 1
  ╰─> [24 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build\lib.win32-cpython-311
      copying yappi\yappi.py -> build\lib.win32-cpython-311
      running build_ext
      building '_yappi' extension
      creating build\temp.win32-cpython-311
      creating build\temp.win32-cpython-311\Release
      creating build\temp.win32-cpython-311\Release\yappi
      "C:\Program Files\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.33.31629\bin\HostX86\x86\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -IC:\Users\x32\AppData\Local\Programs\Python\Python311-32\include -IC:\Users\x32\AppData\Local\Programs\Python\Python311-32\Include "-IC:\Program Files\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.33.31629\include" "-IC:\Program Files\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\VS\include" "-IC:\Program Files\Windows Kits\10\include\10.0.19041.0\ucrt" "-IC:\Program Files\Windows Kits\10\\include\10.0.19041.0\\um" "-IC:\Program Files\Windows Kits\10\\include\10.0.19041.0\\shared" "-IC:\Program Files\Windows Kits\10\\include\10.0.19041.0\\winrt" "-IC:\Program Files\Windows Kits\10\\include\10.0.19041.0\\cppwinrt" /Tcyappi/_yappi.c /Fobuild\temp.win32-cpython-311\Release\yappi/_yappi.obj
      _yappi.c
      yappi/_yappi.c(220): error C2037: l'elemento a sinistra di 'f_state' specifica un '_frame' di struct/union non definito
      yappi/_yappi.c(220): error C2065: 'FRAME_SUSPENDED': identificatore non dichiarato
      yappi/_yappi.c(220): warning C4033: 'IS_SUSPENDED' deve restituire un valore
      yappi/_yappi.c(232): error C2037: l'elemento a sinistra di 'f_code' specifica un '_frame' di struct/union non definito
      yappi/_yappi.c(233): error C2037: l'elemento a sinistra di 'f_code' specifica un '_frame' di struct/union non definito
      yappi/_yappi.c(236): error C2037: l'elemento a sinistra di 'f_code' specifica un '_frame' di struct/union non definito
      yappi/_yappi.c(653): error C2037: l'elemento a sinistra di 'f_code' specifica un '_frame' di struct/union non definito
      yappi/_yappi.c(673): error C2039: 'co_varnames': non Š un membro di 'PyCodeObject'
      C:\Users\x32\AppData\Local\Programs\Python\Python311-32\include\cpython/code.h(103): note: vedere la dichiarazione di 'PyCodeObject'
      yappi/_yappi.c(673): error C2198: 'PyUnicode_AsUTF8': argomenti insufficienti per una chiamata
      error: command 'C:\\Program Files\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.33.31629\\bin\\HostX86\\x86\\cl.exe' failed with exit code 2```

Thanks