Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

perf: filter discovery tokenizes the app and system `Config/Filters.php` on every request

Abierto Apto para principiantes
  • ¿Algo no está bien?
#10,616 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
backend, performance

Línea de trabajo

Empieza en el método privado discoverFilters(), que se llama desde el constructor de Filters, y revisa cómo se pasan los resultados de FileLocator::search() a getClassname(). Añade una comprobación que omita las rutas APPPATH y SYSTEMPATH Config/Filters.php antes de esa llamada, dejando las demás rutas sin cambios. Ejecuta tests/system/Filters/FiltersTest.php; está terminado cuando un locator espía mediante Services::injectMock('locator', ...) no muestre ninguna llamada a getClassname() para los archivos de la aplicación o del sistema, y el filtro personalizado de tests/_support y su alias test-customfilter sigan funcionando.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

Filters::__construct() calls the deprecated discoverFilters() on every request when filter discovery is on, which it is by default. That method finds every Config/Filters.php across all namespaces. For each file, it calls FileLocator::getClassname(), which runs file_get_contents() and token_get_all() on the file.

In a default app, discovery finds only two files:

  • app/Config/Filters.php
  • system/Config/Filters.php

Both get read and tokenized, and then both are skipped, because their class is Config\Filters or CodeIgniter\Config\Filters. So every request pays to parse two files it never uses.

Measurements

PHP 8.3 on macOS, OPcache on, production mode, warm. Each number is averaged over 300 runs.

Case Time
new Filters(...), discovery on (default) ~103 µs
new Filters(...), discovery off ~0.2 µs
FileLocator::search('Config/Filters.php') ~15 µs
FileLocator::getClassname() per file ~42 µs

For a full request to a bare closure route, Services::filters() is about 126 µs. That's the largest single cost left once #10615 lands, at about 14–18% of the request.

Proposal

In discoverFilters(), compare each found path against APPPATH . 'Config/Filters.php' and SYSTEMPATH . 'Config/Filters.php' before calling getClassname(). Skip those two paths with no file read.

  • FileLocator::search() already returns real paths, and APPPATH and SYSTEMPATH are real paths too, so a plain string compare works.
  • Every other file keeps today's class-name check, unchanged. Module and package discovery files are still included as they are now.

With the default setup, the cost drops to the search() call alone, about 15 µs.

Compatibility

  • No public or protected API changes. discoverFilters() is private.
  • There's one edge case. Today, if app/Config/Filters.php declared some class other than Config\Filters, discovery would include it. After this change, that file is skipped. This layout breaks the framework's own conventions, and filter discovery has been deprecated since 4.4.2. So no changelog or upgrade-guide entry is planned.

Tests

Add a regression test in tests/system/Filters/FiltersTest.php. It uses a spy FileLocator, injected with Services::injectMock('locator', ...), that records the paths passed to getClassname(). The test asserts that:

  • getClassname() is never called for the app or system Config/Filters.php.
  • getClassname() is still called for tests/_support/Config/Filters.php, and the test-customfilter alias it adds is still registered.

The existing discovery test (FiltersTest.php:488) keeps covering the third-party path.

Related

  • #10615. It covers config construction cost. This issue is independent and can land separately.
Lenguaje dominante
PHP
Estrellas
6k
Forks
2k
Merge medio
1 d 22 h
PR fusionados (30 d)
59

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de codeigniter4/CodeIgniter4

Todos los issues de codeigniter4/CodeIgniter4

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.