Feature request: Filter stats by function descriptor

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?

[sumerc]

Hey @sm-Fifteen , I have released a new version for Yappi: 1.2.4 😃 . Keep an eye on any hotfixes(maybe?) following days. Other than that, thanks again! This versions fixes most of the issues we have discussed.

[sm-Fifteen]

Fair enough. Once I release two #38 and #41 (which is currently on master) I think we are good to go.

That’s the plan 😉

Incremental stats clearing will come but I will focus my efforts on releasing these first.

Yeah, the solution I have right now is by no means ideal, but it does the job reasonably enough that it’s not a priority for me at the moment.

https://github.com/sm-Fifteen/asgi-server-timing-middleware/blob/eaa91f18cb537b0ad1a7986f2e9e11ae626f82bc/asgi_server_timing/middleware.py#L79-L80

The reason I want this is your middleware implementation will indeed might be a reference implementation for all other ASGI frameworks as well 😃

With the current structure, I think it should work for any application using the ASGI protocol (though I’ve only specifically tested FastAPI). I’ll be changing the interface a bit before release (I definitely need to replace those __qualname__ strings with arrays of callables/coroutines), but there shouldn’t be any need to adapt it to work with, say, Sanic or Quart since all the FastAPI/Starlette-specific things are actually in the configuration.

app.add_middleware(ServerTimingMiddleware, calls_to_track={
    "db_exec": [sqlalchemy.engine.base.Engine.execute],
    "db_fetch": [
        sqlalchemy.engine.ResultProxy.fetchall,
        sqlalchemy.engine.ResultProxy.fetchone
    ],

    # All steps of the generated fastapi.routing.get_request_handler app
    "1deps": [fastapi.routing.solve_dependencies], # `Depends` execution
    "2endpoint": [fastapi.routing.run_endpoint_function], # Since FastAPI 0.49.2
    "3valid": [fastapi.routing.ModelField.validate], # Pydantic model validation
    "4encode": [fastapi.encoders.jsonable_encoder], # JSON encoding
    "5render": [starlette.responses.JSONResponse.render], # Respnse (JSON) rendering
})