Profiler Laravel Package

Product Decisions This Supports

• Performance roadmap prioritization. Profiling data (via XHProf/uprofiler) tells you which endpoints, jobs, or code paths actually burn CPU and wall time — so roadmap debates about "we need to make the app faster" turn into ranked, evidence-backed tickets instead of anecdotes.
• Build vs. buy for observability. This package is a credible "build-light" option: it wraps a proven profiler and lets you choose where results land. That directly informs the decision between a paid APM (Datadog, New Relic, Blackfire, Tideways, Sentry Performance) and an in-house, self-hosted profiling setup.
• Persistence/architecture decisions. With multiple persistence layers, the PM can treat "where does profiling output live?" as a product question (files on disk vs. a database table you can query vs. export to a dashboard), which shapes retention, privacy, and incident-review workflows.
• Release-gating and regression policy. Profiling runs before/after a release support a go/no-go rule: "no endpoint regresses more than X% in mean latency." This is a policy decision the PM owns, and the tool provides the raw data to enforce it.
• Incident post-mortems and capacity planning. When a feature page 500s or a queue backs up, profile snapshots give the postmortem a factual root cause, and trend data informs horizontal-scaling vs. code-fix decisions.
• Make-or-keep decisions for legacy code. Profiling exposes hot spots in older PHP modules, which supports sunsetting, rewriting, or leaving alone — a recurring PM decision in mature codebases.
• Cost-of-inaction framing. "What would we pay in infra or churn if we don't profile?" becomes answerable with real numbers rather than guesses.

Caveat a PM should weigh up front: 14 stars, an unresolvable repository link, and a low opportunity score mean this is an early package. It supports decisions for a small team or a spike; it should not be load-bearing for a large platform without a fork-and-vendor plan.

When to Consider This Package

Consider it when:

• You have a PHP codebase already running XHProf or uprofiler (or are willing to install the PHP extension), and want a thin, MIT-licensed wrapper rather than a vendor contract.
• Your team is budget-constrained and a paid APM is hard to justify for a monolith with low-to-moderate traffic.
• You need self-hosted / data-residency-safe profiling — output stays in your files or your database, not a third-party SaaS.
• You want pluggable persistence so profiling output can feed an existing internal dashboard or a SQL table your team already queries.
• You're running a time-boxed performance investigation (a spike) where a lightweight tool beats a procurement cycle.
• You value low lock-in: MIT license, small surface area, easy to fork.

Look elsewhere when:

• You need Laravel-native, zero-config tracing — Laravel Telescope, Octane-aware tooling, or Clockwork are better fits.
• You need distributed tracing across services, OpenTelemetry compatibility, or sampling that is safe at high request volume.
• You need flame-graph UX, alerting, long-term data retention, or vendor support — that's Blackfire/Tideways/Datadog territory.
• You're on modern PHP 8+ only and can't rely on XHProf/uprofiler extension availability (note this package's era and maintenance signal).
• Active maintenance and community support are hard requirements. At 14 stars with an unknown repository, treat it as unmaintained until proven otherwise; a fork means you own it.
• Your organization lacks anyone who knows XHProf output — the tool's value depends on a reader.

How to Pitch It (Stakeholders)

For executives (30-second version): We're evaluating a small, free, MIT-licensed PHP profiling library so we can see exactly where the application spends its time — per endpoint, per release. The payoff is a defensible answer to "what do we fix next?" and a cheaper alternative to a five- or six-figure APM contract while we're small. The risk is maturity: the project has minimal community adoption, so my recommendation is a time-boxed pilot on one service, with a decision gate — if it delivers profiling data we actually act on, we either adopt it behind a vendor/fork plan or graduate to a paid APM; if not, we lose a week, not a quarter.

For engineering leadership: The package wraps XHProf/uprofiler and gives us pluggable persistence, so profiling output can land wherever our stack already looks — files during a spike, a database table for trend analysis. It's deliberately narrow and MIT-licensed, so forking is cheap. Known constraints: it presumes the XHProf extension, isn't Laravel-idiomatic, has no flame-graph UI, no distributed tracing, and effectively no upstream community. That makes it a good spike tool and a poor platform dependency — I'd want a named owner and a two-week evaluation before anything else depends on it.

For the wider team: This buys us faster, evidence-based performance conversations and a performance-regression gate we control. It does not buy us APM-grade dashboards, alerting, or on-call support. Framed honestly, it's a cheap experiment with a clear downside cap and a genuine upside if profiling becomes part of how we ship.