Una noche, mientras discutía las dificultades de desarrollar un linter para PHP en Go con Iskander @quasilyte , Iskander mencionó que las pruebas toman mucho tiempo cuando se ejecutan localmente (alrededor de un minuto y me parece que para Go es bastante largo). Comenzamos a investigar, y rápidamente quedó claro que las pruebas que ejecutan NoVerify (el nombre del linter) en el modo con el detector de carrera encendido están principalmente "desacelerando" . El repositorio phpstorm-stubs se indexa para cada lanzamiento, que contiene todas las definiciones de funciones / clases / constantes integradas que están en PHP, y la indexación de este repositorio toma aproximadamente 4 segundos en una máquina de 4 núcleos (tenga en cuenta que sin un detector de carreras todo es mucho más rápido). Dado que hay varias ejecuciones de este tipo, una para cada proyecto de código abierto probado, el tiempo total de ejecución de todas las pruebas puede llevar minutos. NoVerify se posiciona como un linter muy rápido para PHP, por lo que, por supuesto, este rendimiento es un poco triste y era necesario encontrar algún tipo de solución.
NoVerify arquitectura
Para empezar, todavía vale la pena hablar un poco sobre cómo funciona NoVerify. El trabajo de Linter se divide en dos grandes fases: indexación y análisis directo.
La indexación de proyectos significa que las definiciones y tipos de todas las funciones, clases, métodos, constantes y variables globales se extraen de todos los archivos PHP, y toda esta información se almacena en la RAM para un acceso rápido. Esta información también se almacena en la memoria caché del disco en formato gob para evitar la necesidad de analizar todo el proyecto cada vez. Es importante que incluso para analizar un solo archivo, se debe indexar todo el proyecto., porque si hay una carga automática para clases en PHP, entonces no existe tal cosa para funciones, constantes y aún más variables globales, y se pueden definir en cualquier lugar. Por supuesto, en los proyectos PHP modernos, generalmente solo se usan clases y tales problemas no surgen, pero para proyectos con una larga historia esto sigue siendo relevante. Fue la necesidad de indexar todo el proyecto para su análisis la razón para escribir NoVerify en Go, ya que este lenguaje soporta bien el multihilo, lo que significa que podrá indexar el proyecto mucho más rápido de lo que es posible en PHP.
(, , ), . , , ( , phpstorm-stubs 90+% ). //, .
phpstorm-stubs
, , , , phpstorm-stubs, , , «» (.. ) // PHP, 25% , , . , : phpstorm-stubs «» , , , , , , .., , .
«» :
, . , phpstorm-stubs .
phpstorm-stubs , , .
, gob.
, phpstorm-stubs , Go- phpstorm-stubs . , , , 2-3 .
, (2), . , (1), , , . , , Go phpstorm-stubs ~200 (.. 20 ), , 18 , , .
?
, golden- , , , - . , , phpstorm-stubs. , -.
, ( Laravel, composer create-project --prefer-dist laravel/laravel blog, 1.6 PHP) 450 ( 4 ), NoVerify , , , , language server.
/
Go- 1.6 20-60 , , , , . .
: noverifyturbo 20 100 , ~80 1.6 PHP-.
, - NoVerify, , NoVerify. , .
-
: , Go- fmt.Printf("%#v", value).
, , , , GoStringer(), .
PHP- Go-, map[string]func()*PerFileCache, ( PHP- , , ), , PHP-. , , , , map ( - , ), , , , map , .
+ , , - stat() , .
Laravel 1.6 , composer create-project --prefer-dist laravel/laravel blog , :
, 1 : 4
-, 1 : 400
, 12 : 1 (10 )
-, 12 : 240 (800 )
, - , , - map , , . , - , , .
— , , , , ( Google, ).
NoVerify Go, , phpstorm-stubs «» . . , , NoVerify workflow , PHPStorm VS Code , .