performance profile using Scalene

[williballenthin]

https://github.com/plasma-umass/scalene

Scalene: a high-performance, high-precision CPU, GPU, and memory profiler for Python with AI-powered optimization proposals

Scalene is a high-performance CPU, GPU and memory profiler for Python that does a number of things that other Python profilers do not and cannot do. It runs orders of magnitude faster than many other profilers while delivering far more detailed information. It is also the first profiler ever to incorporate AI-powered proposed optimizations.

[devs6186]

Hi, I’d love to work on this. Before I start implementing anything, I just wanted to clarify the intended UX and scope.

Would you prefer this to be:
A user-facing CLI flag (for example, capa --profile) that runs the analysis under Scalene
A separate subcommand like capa profile to keep profiling more isolated
Or more of a developer-oriented workflow that’s documented rather than exposed directly through the CLI?

My plan is to keep Scalene as an optional dependency and make sure existing workflows aren’t affected. I’m happy to go with whichever approach fits best with the project’s long-term direction.

Thanks!

[devs6186]

The possibe approaches, just a few snippets for you to understand:

i am thinking in this direction

1. User-facing flag (capa --profile)

This would wrap the main execution under Scalene when the flag is provided.

if args.profile:
    run_with_scalene(main_analysis)
else:
    main_analysis()

2.Separate subcommand (capa profile)

This would isolate profiling logic into its own command, keeping the main CLI clean.

@cli.command("profile")
def profile_command(...):
    run_with_scalene(main_analysis)

3.Developer-focused workflow
Instead of exposing profiling via CLI, we could document a workflow like:

scalene -m capa ...

Proposed Next Steps (once direction is confirmed)

• Add optional dependency handling with graceful fallback
• Ensure no impact on existing CLI behavior
• Add minimal tests to confirm profiling mode does not break execution
• Update documentation with usage examples
• Optionally support HTML/text output configuration

If this approach sounds aligned with the project goals, I’d be happy to take this issue.

[williballenthin]

this issue describes a likely temporary research effort to run capa under the linked tool, identify hotspots, and potentially fix them. do not propose to add additional flags to capa that most users won't touch.

we don't need any help figuring out how to invoke the profiler. you are welcome to try the profiler and then propose data driven fixes to capa that improve performance without changing its behavior. there is no expectation that you do. otherwise, this issue serves as a tracking issue for something any dev might want to try when they have some free time.