Profiling Laravel Package

Product Decisions This Supports

• Performance budgeting and ship/no-ship gates. The package provides block-level timing on top of the high-resolution timer (hrtime), so it answers "is this endpoint/job inside our latency budget?" with measured numbers rather than intuition. That is a release-criteria decision, not just an engineering nicety.
• Roadmap triage for refactor investment. Instrumenting suspect code paths first lets you rank modules by real measured cost and spend the next sprint's capacity on the top two hot paths instead of on whichever component complained loudest.
• Build vs. buy for internal tooling. The package is essentially a thin timer with a fluent interface. Evaluating it is a fast way to price the alternative: roughly a day of engineering to build and own a small Timer abstraction in-house versus taking a dependency. This is the central PM decision here, and for most teams the in-house option wins.
• Coverage gap for non-HTTP workloads. Laravel Telescope, Debugbar and Clockwork are excellent at request-level introspection but are awkward for queue workers, artisan commands, scheduled tasks and long-running importers. A framework-agnostic timer is a legitimate fit for those surfaces.
• Deciding whether to pay for APM. Cheap, self-hosted instrumentation now produces the baseline evidence needed to justify (or reject) a Blackfire, Datadog or New Relic line item later. It converts an opinion into a procurement case.
• Regression detection on critical paths. Timing assertions around a handful of revenue-critical operations in CI give you an early warning on accidental N+1s and synchronous I/O before customers find them.
• Use cases that map well: batch import throughput checks, scheduled-job duration tracking, third-party API call timing, cache-miss cost measurement, and quick spikes on legacy code you do not want to refactor to profile.

When to Consider This Package

Consider it when:

• You need coarse-grained timing of discrete code blocks in CLI, queue or console contexts where the Laravel-native debug tools do not reach.
• Legal has cleared GPL-2.0 for your distribution model — or your use is strictly internal and never distributed to customers.
• You want profiling with zero extension installs (pure PHP, no Xdebug/PCOV requirement on the host), which matters in restricted or containerized environments.
• You are doing a one-day spike and want prior art rather than a design discussion.
• You are willing to vendor, fork or wrap it behind your own interface so the dependency never becomes load-bearing.

Look elsewhere when:

• The license is a blocker. GPL-2.0 is copyleft; for a distributed or commercially licensed product this generally fails legal review. Laravel Telescope, Laravel Debugbar and Clockwork are MIT and cover more ground. Start there.
• You need request-level introspection — queries, cache hits, timeline UI, exception context. That is Telescope/Debugbar/Clockwork territory, not this.
• You need a real sampling profiler with flamegraphs — Xdebug plus a viewer, or Blackfire. A timer tells you how long, not where inside.
• You need production APM at scale — distributed tracing, alerting, retention. Buy it.
• You need maintenance assurances. The signals here are weak: one star, zero dependents, effectively no community, and a single maintainer. No evidence of a security-response process. Do not make this a transitive dependency of anything customer-facing.
• You want Laravel integration out of the box. This is a framework-agnostic toolbox; service provider, config publishing, facades and middleware are yours to write.

How to Pitch It (Stakeholders)

To executives: This is a small timing utility, not a platform or an observability vendor. Its value is the discipline it encourages — measuring before optimising — not the code itself. The cheapest path is to standardise on a timer abstraction we own behind an internal interface, and treat this package as reference prior art. That gives us the measurement capability with none of the dependency risk, and costs about a day.

To engineering: Low ceremony, no extensions, works in queue and CLI contexts where Telescope does not. But it is unmaintained-looking, has one star and no dependents, and the API is thin enough that wrapping it is nearly as much work as replacing it. If we do adopt it, pin the version, vendor it, put it behind our own Profiler interface, and confine it to internal tooling.

Risks to state plainly:

• License: GPL-2.0 is copyleft. This is the single largest blocker and needs a legal ruling before any code is written, not after.
• Bus factor 1 with no visible community, tests or release cadence.
• Opportunity cost is low but so is leverage — roughly 50 lines of hrtime code replicates the useful surface.

The ask: one day of engineering for a spike that instruments two or three known-slow paths in a queue worker, wrapped behind our own interface, with a recommendation at the end: adopt, vendor, or replace with in-house code. Default expectation is replace with in-house code, using this package only as a design reference.