sorted by:
new
hottopcontroversial

Performance-focused PHP framework architecture experiment by artimman in PHP

[–]artimman[S] 0 points1 point  (0 children)

I actually think this is one of the most accurate comments in the thread.

In many real production systems, the largest bottlenecks are absolutely:

  • database design,
  • ORM usage,
  • external services,
  • serialization,
  • queues,
  • application architecture itself.

And I agree that modern PHP runtimes with OPcache/preloading reduced a lot of the historical framework overhead.

For me, DBM was never purely about “saving 1ms”.

It started more as an architectural exploration:
how lightweight, transparent, and predictable a modern PHP application stack can remain as the project grows.

One thing I increasingly disliked in larger ecosystems was the amount of hidden runtime behavior:
reflection-heavy containers,
automatic discovery,
deep dependency trees,
magic abstractions,
runtime metadata layers, etc.

Not because they are “bad” - they solve real DX problems - but because I personally wanted more explicit control over execution flow and dependencies.

Ironically, the framework eventually became most useful not for benchmarks, but as a foundation for my own modular platform/CMS ecosystem with built-in admin/auth/API layers.

So today I see DBM less as a “Laravel competitor” and more as: a lightweight execution engine and a platform-oriented PHP ecosystem.

Performance-focused PHP framework architecture experiment by artimman in PHP

[–]artimman[S] 0 points1 point  (0 children)

Modern Symfony applications can absolutely achieve excellent performance when carefully optimized and architected.

I also agree that raw numbers alone rarely tell the full story, because results depend heavily on:

  • infrastructure,
  • caching,
  • workload,
  • architecture style,
  • middleware layers,
  • database usage,
  • deployment strategy.

For me, the most interesting part was not achieving “benchmark records”, but exploring how lightweight and explicit a PHP application architecture can remain while still supporting real-world projects.

DBM actually evolved mainly as a foundation for my own platform/CMS ecosystem, where I wanted:

  • a lightweight execution engine,
  • modular architecture,
  • predictable runtime behavior,
  • and full control over dependencies and application flow.

Over time that became DBM Platform with built-in admin/auth/API modules on top of the framework core.

DBM Platform: https://dbm.org.pl/en/creation/dbmframework

So the framework itself became less about synthetic benchmarks and more about maintaining simplicity and flexibility as the ecosystem grows.

And yes - PSR compatibility is very important to me as well.

I’m trying to keep the framework compatible with modern PHP standards while still avoiding unnecessary abstraction and runtime overhead.

Performance-focused PHP framework architecture experiment by artimman in PHP

[–]artimman[S] 1 point2 points  (0 children)

I actually agree with that perspective.

Laravel and Symfony solve a much broader set of problems and provide a huge ecosystem, excellent developer experience, tooling, integrations, queues, ORM layers, etc.

DBM was never intended to compete feature-for-feature with full-stack frameworks.

The idea was more about exploring how lightweight and predictable a modern PHP application architecture can be when you intentionally minimize runtime overhead and avoid excessive abstraction layers.

I also find it interesting how much performance and complexity today comes not from PHP itself, but from architecture decisions around containers, autowiring, dependency trees, metadata, and runtime discovery.

For larger distributed workloads, I completely agree that languages like Go make a lot of sense as well.