Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Zend Memory Laravel Package

zendframework/zend-memory

Zend Memory provides PHP memory-management utilities, including a memory manager, memory objects, and storage containers with limit and sliding-window strategies. Useful for controlling memory in long-running processes and cache-like workflows.

Deep Wiki
Context7

Product Decisions This Supports

  • In-process memory budgeting for long-running workers. If the roadmap includes queue workers, Octane, or Swoole processes that accumulate large objects (parsed documents, image transforms, generated reports), this component's core pattern—register objects against a memory ceiling and evict least-recently-used entries when the budget is exceeded—maps to a real reliability feature: "workers absorb large batches without OOM restarts."
  • Build vs. buy for a bounded in-memory object cache. The component is small and single-purpose. The decision it actually informs is whether to write ~150 lines of eviction logic in-house, adopt the maintained Laminas fork, or push the concern to Redis. On its own merits it does not justify a vendor dependency.
  • Scope negotiation on caching architecture. When engineering proposes "keep expensive objects in PHP memory for speed," this package is the concrete prior art to evaluate. It helps frame in-process caching as a stopgap bounded by a budget, not a substitute for a shared cache tier.
  • Maintenance-budget forecasting. The archived status is itself a roadmap input: no security patches, unverified PHP 8.x compatibility, no upstream. Any feature leaning on it carries a permanent maintenance tax that should be priced into the estimate.
  • Explicit non-use case. This is not relevant to user-facing features or plain request-scoped memory concerns—PHP's lifecycle handles those—and it is the wrong answer anywhere the correct answer is "store it in Redis."

When to Consider This Package

Consider it only if all of the following hold:

  • You run genuinely long-lived PHP processes (queue workers, Octane, Swoole, ReactPHP) where one process accumulates memory across many jobs.
  • You have a measured OOM or restart problem traced to object accumulation—not an unbounded array or a leak in your own code.
  • Your PHP version falls inside the package's supported range; it predates modern PHP 8.x, so verify compatibility before anything else.
  • You accept that you cannot rely on upstream fixes and are prepared to vendor or fork the code.

Look elsewhere when:

  • You need a cache. Use Redis or Memcached through Laravel's cache. It is shared across processes, observable, and evicts under real memory pressure.
  • You need worker memory limits. queue:work --memory already restarts workers at a threshold and solves most of the operational problem at far lower risk.
  • You want this exact code, maintained. Use laminas/laminas-memory—same lineage, actively maintained, PHP 8 compatible. Adopting the archived Zend package when the maintained fork exists has no defensible rationale.
  • You only need the pattern. A small internal budget class with LRU eviction is easy to write, test, and own; that beats an unmaintained dependency.
  • You need production evidence. Seventeen stars and a 2019 final release mean negligible adoption; treat any "battle-tested" claim as unverified.

How to Pitch It (Stakeholders)

Executive summary. This is a legacy, archived Zend Framework component for capping and evicting in-memory objects. It is not a strategic dependency: no active maintenance, no security patching, minimal community footprint, and a maintained successor exists. Recommended position: do not adopt. Use it as reference material for a pattern, not as a dependency.

For engineering. The valuable idea is a memory budget with LRU eviction inside long-running processes. If we have a demonstrated worker-memory problem, solve it in this order: (1) tune queue:work --memory and fix unbounded accumulations in our own code; (2) use laminas/laminas-memory if we want proven code; (3) write a small internal budget manager we own end to end. Do not introduce the archived package into a new feature.

Roadmap impact. Near zero. If a worker-stability initiative is on the roadmap, this package contributes a design reference and a short spike—not a build-vs-buy decision. Cap evaluation at one day; redirect the savings into memory observability around workers, which surfaces the problem earlier and far cheaper than an eviction layer.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
tequilarapido/trackit
gregsphotography/site-builder-filament
cabaoctavio/laravel-query-log
gregsphotography/site-builder-components
io-digital/clickatell
snowsoft/laravel-admin
oxygen/auth
relicsoftware/barakah-payment-gateway
tobya/work-with-composer
equipc/laravel-email-validator
equipc/laravel-email-database-log
adedsec/nova-translated-labels
wazza/laravel-db-encryption
hokny/laravel-generator
vonsogt/backup
jengo/queues
jeremykenedy/laravel-observability
coleus/frame
thtg88/journalism
filagora/filagora-ai-forums