Dev performance metrics

[KirtiPriya07]

📝 Description

Adds a simple, low-cost performance monitoring system for SmythOS agents and LLMs.

Automatically instruments agent components (no code changes needed) and records timings, memory, data flow, and LLM-specific info (tokens, estimated cost, context use).

Provides programmatic APIs (AIPerformanceCollector, AIPerformanceAnalyzer) and example scripts so developers can fetch reports and metrics.

Includes a basic CLI (smyth agent:performance) for a real-time dashboard, reports, component analysis, and exports (JSON/CSV/Prometheus).

Built to be lightweight (sub-millisecond per component) and safe (no raw sensitive data stored).

Core instrumentation and analysis tests passed locally; CLI features still need broader end-to-end testing.

🔧 Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 📚 Documentation update
• 🔧 Code refactoring (no functional changes)
• 🧪 Test improvements
• 🔨 Build/CI changes

✅ Checklist

• Self-review performed
• Tests added/updated
• Documentation updated (if needed)

[alaa-eddine-k]

Hi @KirtiPriya07 .
Wow that's a really cool contribution. we are also internally working on some upcoming monitoring services, and this once can definitely be part of it.

I will ask you to a change in order to make sure that this does not interfer with our future Monitoring connectors.

Instead of having Performance Manager directly under subsystems (src/subsystems/PerformanceManager)
please put it under (src/subsystems/Monitoring/Performance.service)

so the subsystem (family) is "Monitoring", the service is "Performance" with the generic PerformanceConnector class and the specific connector is LocalPerformanceConnector

The reason for this is that we will be adding other Monitoring services like a real time system resources (CPU, RAM ...etc) monitors.

Also do you have any output example / screenshot of the current CLI implementation ?

Thank you very much !

[KirtiPriya07]

@alaa-eddine-k Hi!, I understand, will definitely relocate and send you screenshots in a while.

[alaa-eddine-k]

I took some time to review the code in more details, I was not able to test it the example code fails.
but here are a few notes.

1 - The PR contains modifications to Component base class ==> this is not allowed by design, as it breaks the concerns separation rule. a connector should not require dedicated functions/structures outside of itself. so instead of storing data inside of static fields, or declaring static fields inside of Component class, these structures should be part of the Performance connector or stored in separate data structures.

2 - Your LocalPerformanceConnector.class.ts does not have to redefine request() method unless there is something specific to your connector, in your case you can simply inherit the request() method from the parent (PerformanceConnector class)

3 - The performance monitoring should not be enabled by default, even if the overhead is tiny, it's not an operation that we want to have enabled by default, so by default we consider it disabled, and we can enable it using a function call.
ideally we should be able to start/stop/restart performance monitoring in realtime (the connector should expose two methods : startMon, stopMon (don't use start()/stop() they are already used to start/stop the connector itself)