| Respuesta: Realmente existen 5800 funciones en el entorno GLOBAL de PHP ?
Uf, a ver, aqui hay un montón de cosas.....
Sobre las 5800 funciones definidas en el "global space"..(qué es eso? no será global namespace?)...
Y? Cuantas funciones tiene C definidas en el "global space", linkando sólo la stdlib y poco más?
Que sería "mejor" que estuviera todo en clases? (sacándolas del namespace global, y metiéndolas en clases definidas en el namespace global, o en sub-namespaces)...Pues..es posible.
Pero más problema me parece a mí que el criterio de nombrado de funciones , y , peor, el orden de parámetros, es variable.Por qué existe mysql_connect, pero no str_len? Mientras el primer criterio es una especie de pseudo-namespace, el segundo sigue el criterio de parecerse a C.
Lo de qué va primero en muchas funciones de arrays, cadenas, si el haystack o el needle, es algo que me lleva a tener el manual siempre abierto..
Sobre "que ocupan memoria"..Qué lío hay montado...A ver..Para empezar, PHP tiene una funcionalidad "core", y "extensiones".Así que, cuántas funciones de las "definidas por PHP" están en la memoria de tu ordenador, depende muchísimo de qué extensiones tienes activadas.Creo que casi nadie en su sano juicio tiene activadas todas las extensiones de PHP en su servidor, así que el número de 5800, numero de funciones definidas en PHP como lenguaje, no tiene nada que ver con el número de funciones activas en tu sistema.
Ahora, sobre el uso de "RAM".Un programa en memoria tiene 2 cosas: código y datos.Del programa que aquí estamos hablando, es PHP, que está dentro de un envoltorio, sea el cli, sea apache, sea fpm.
Cuánto ocupa esto en RAM, y si debo preocuparme o no.Pueess..A ver...yo más o menos uso las mismas extensiones por defecto desde hace..uhh..unos 12 años...Más las típicas 2 o 3 extensiones especiales para el proyecto en el que esté...Pero vamos...que si PHP se ejecutaba estupendamente en hardware de 12 años, imagínate hoy!
Todo lo que está escrito en PHP son *datos* del programa PHP.Pero, aunque tengas 200 procesos de apache lanzados (sean threads o forks), lo que es propio de cada thread son las páginas RAM de datos, no de código, que son compartidas, y que es donde reside el código compilado de las "5800" (muchisimas menos) funciones que tienes en tu PHP.
Básicamente, a nivel de RAM usada para *código*, te da igual que haya 1 o 2000 procesos.Ocupan lo mismo.
Ahora veamos el código "complejisimo" de esas funciones.Muchísimas, si no casi todas las funciones PHP, no implementan la funcionalidad que hacen, sino que a su vez llaman a una librería.mysql_connect llama a la API de mysql, la cual está en una librería dinámica de mysql.
Ojo a la palabra *dinámica*.Las librerías *dinámicas* permiten que sean mapeadas en los espacios de memoria de distintos procesos.
Esto significa que, con que haya 1 solo proceso en todo el sistema , que haya cargado las librerías típicas de C (strlen, strdup,etc,etc), con que haya un solo proceso en todo el sistema que haya cargado las librerias de expresiones regulares, etc,etc...el coste de RAM que supone que PHP también las cargue...es prácticamente cero.
PHP hace sus historias de conversión de tipos, de mapeo de tabla de simbolos,etc...Pero, *por supuesto*, ni reescribe la función "preg_match", y el coste de cargar la librería que sí la implementa, es *cero*.
En definitiva, de lo que habla el blog es una cuestión *estética* de la *definición* del lenguaje.No tiene nada que ver con el rendimiento...
A veces se echa de menos trabajar con 64k de RAM... |