Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

perf: reduce per-row and per-access overhead in entity and model casting

Offen
  • Stimmt etwas nicht?
#10,618 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Refactoring
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
php
Bereich
backend, performance

Rechercherichtung

Start with DataCaster::castAs() for the cast-type parsing, DataConverter::reconstruct() for the duplicate syncOriginal() call after injectRawData(), and Entity::__get(), __set() and toArray() for the getter/setter lookup. Run the benchmark or the DataCaster, DataConverter and Entity tests before and after each of the three commits. Done means the listed tests pass, including the documented behavior change for entities that override injectRawData(), and the proposal's timing targets hold.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Problem

Loading rows through a model with casts, especially as entities, repeats the same work on every row and every field:

  1. DataCaster::castAs() parses the type string on every cast. For each value it runs str_starts_with, a match, a preg_match(), explode/array_map(trim) and a trim, all to turn something like '?int' or 'json-array' into a handler key and params. The handler itself often costs less than the parsing.
  2. DataConverter::reconstruct() calls syncOriginal() twice for each entity. It calls injectRawData(), which already calls syncOriginal(), and then calls syncOriginal() again. When attributes hold arrays or objects, each sync normalizes them and runs json_encode().
  3. Entity::__get() and __set() rebuild the getter or setter name on every access. They run str_replace/ucwords, then make two method_exists() calls. toArray() repeats this for every key.

Measurements

PHP 8.3 on macOS, OPcache on, production mode, warm. The test entity has 10 columns, 6 casts (int, ?int, bool, json-array, float, int-bool) and the default $dates.

Case Time
1000 rows → arrays (fromDataSource) 3.2 ms
1000 rows → entities (reconstruct) 6.3 ms
1000 rows → entity with no casts 2.0 ms
Step Cost
castAs() for an int field 0.33 µs
IntegerCast::get() called directly 0.07 µs
syncOriginal() with an array attribute 1.2 µs per call
Getter-name build + 2× method_exists() ~0.1–0.2 µs per access
__get() on a plain field 0.46–0.58 µs
toArray() with 10 keys 7.6–11 µs

Proposal

1. Cache parsed cast types (DataCaster)

Add a private static cache keyed by the type string. It stores only the parsed result: base type, params and the nullable flag.

  • Handlers are not cached. Each instance still looks up the handler in its own $castHandlers, so instances with different custom handlers keep working.
  • The non-strict 'nullable' param is still added after the cache lookup.
  • An unknown type still throws on every call.
  • Why static: each entity has its own DataCaster, so a per-instance cache would rarely get a hit. The parse depends only on the string, so the cache is safe across Worker Mode requests. It also can't grow without limit, because type strings come from code, not from input.
2. Sync originals once (DataConverter::reconstruct())

Remove the second syncOriginal() call. injectRawData() already syncs.

3. Per-class getter/setter map (Entity)

On the first access, build a map of each entity class's get*, _get*, set* and _set* methods using ReflectionClass::getMethods(), with lowercase keys. Lookups then replace the two method_exists() calls.

  • Bounded memory: the map depends on the class, not on input. Keys passed to fill() from request data can't make it grow.
  • Same lookup rules: lowercase keys match PHP's case-insensitive method names. Reflection includes private methods, so results match method_exists() exactly.

Estimated gains

Fixes 1 and 2 bring 1000 entities from about 6.3 ms to about 3.6 ms, roughly 40% faster. Array results drop from about 3.2 ms to about 1.7 ms. Fix 3 removes about 25–35% of the cost of each __get()/__set() call, which matters most in toArray() and in views that read many properties.

These are estimates from micro-benchmarks, not from the final code.

Behavior changes (4.8)

Only fix 2 changes behavior. If an app entity overrides injectRawData() without calling syncOriginal(), reconstruct() no longer syncs for it. Such an entity will report every field as changed after a find(), and save() will write all columns. That override is already broken for any other caller of injectRawData(). This will be listed in the v4.8.0 changelog under "Behavior Changes", with a note in upgrade_480.rst saying overrides must call syncOriginal().

Fixes 1 and 3 change no behavior.

Not changing

  • Lazy DataCaster creation in the Entity constructor (~5%). Subclasses can read the protected $dataCaster property directly and would get null.
  • The non-strict is_subclass_of() checks and the toArray() filter closure. Each costs under 2%.

Plan

One PR with three commits, one per fix. Fix 2 also includes the changelog and upgrade-guide entries.

Tests

  • DataCasterTest:
    • Two instances with the same type string but different custom handlers each call their own handler.
    • Non-strict ?type still adds nullable, and strict mode doesn't.
    • An unknown type throws on every call.
  • DataConverterTest:
    • A reconstructed entity reports hasChanged() === false.
    • An entity that overrides injectRawData() without syncing now reports changes. This test documents the behavior change.
  • EntityTest:
    • Getter lookup ignores case.
    • _getX wins over getX.
    • Inherited getters are found.
    • A private getter behaves as it does today.
    • Maps are kept separate for each class.

Related

  • #10615, #10616, #10617
Vorherrschende Sprache
PHP
Sterne
6k
Forks
2k
Ø Merge
1 T. 22 Std.
Gemergte PRs (30 T.)
59

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus codeigniter4/CodeIgniter4

Alle Issues in codeigniter4/CodeIgniter4

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.