Clases con métodos compartidos

[mariano_donati]

Hola a todos. Me gustaría si alguien conoce que diferencias hay cuando creamos una clase con métodos compartidos y una clase con métodos públicos. ¿La clase sigue ocupando el mismo lugar en memoria? ¿Los métodos compartidos se almacenan en otro lugar?. Principalmente, me interesa saber si existe alguna diferencia en rendimiento entre una clase que tenga todos sus métodos estáticos
y una que tenga los mismos métodos, pero públicos.
Saludos.

[santhy]

Si con "compartidos" te refieres a los estáticos (static function XXXX() ) entonces la diferencia (en teoría) es esta:
una función static test() se llama como NombreClase::test() (y no debe llamarse como $objeto->test(); y que produce un STRICT_ERROR).
Por tanto, es lógico pensar que ocupa menos espacio en memoria, al no necesitar el puntero al objeto implícito $this
Sin embargo, los métodos no-estáticos (como $objeto->test() ) sí necesitan hacer referencia a este puntero.
Además, por cada objeto creado se duplican todas las variables (las funciones creo que no, pero esto no puedo asegurarlo) en el espacio de memoria de cada objeto (pues son distintas para cada objeto); sin embargo, las variables estáticas, en este caso, tampoco son duplicadas.

Espero haberte entendido y aclarado algo

[mariano_donati]

Si, era hacia eso donde apuntaba mi pregunta. Y ahora tengo las cosas un poco más claras. A ver si alguien puede seguir aportando algunas cosas más.
Gracias por tu respuesta.

[GatorV]

Tema trasladado a PHP Orientado a Objetos.

[enriqueplace]

Iniciado por mariano_donati

Hola a todos. Me gustaría si alguien conoce que diferencias hay cuando creamos una clase con métodos compartidos y una clase con métodos públicos. ¿La clase sigue ocupando el mismo lugar en memoria? ¿Los métodos compartidos se almacenan en otro lugar?. Principalmente, me interesa saber si existe alguna diferencia en rendimiento entre una clase que tenga todos sus métodos estáticos
y una que tenga los mismos métodos, pero públicos.
Saludos.

La pregunta es bastante improcedente... ¿estás pensando solo en optimizar de forma mecánica las clases? O sea, si la respuesta es que consume menos mejoria un "método de clase" (estático), de ahora en más, ¿harás todas las clases estáticas con métodos estáticos?

No tiene sentido la dirección de la pregunta.

[enriqueplace]

Iniciado por santhy

Si con "compartidos" te refieres a los estáticos (static function XXXX() ) entonces la diferencia (en teoría) es esta:
una función static test() se llama como NombreClase::test() (y no debe llamarse como $objeto->test(); y que produce un STRICT_ERROR).
Por tanto, es lógico pensar que ocupa menos espacio en memoria, al no necesitar el puntero al objeto implícito $this
Sin embargo, los métodos no-estáticos (como $objeto->test() ) sí necesitan hacer referencia a este puntero.
Además, por cada objeto creado se duplican todas las variables (las funciones creo que no, pero esto no puedo asegurarlo) en el espacio de memoria de cada objeto (pues son distintas para cada objeto); sin embargo, las variables estáticas, en este caso, tampoco son duplicadas.

Espero haberte entendido y aclarado algo

Mmm... tienes idea en el orden de cuanto "ahorro" estamos hablando de memoria y por cuanto espacio de tiempo?

Este tipo de "optimizaciones" no tienen sentido. Es como cuando dicen "cada vez que dejo de usar una variable le hago unset".... ¿no es más fácil esperar a que termine la ejecución del PHP?

En "situaciones normales" (no levantar una consulta gigante en un array en memoria y luego recorrerlo) este tipo de "estrategias" no surten ningún efecto y lo que hacen es generar "desastres" a la hora de diseñar sistemas porque ponemos solo énfasis en la "optimización", perdiendo en foco en cumplir con la funcionalidad requerida.

PD: si me dieran un dolar por cada vez que me preguntan sobre "cómo optimizar al extremo el código PHP", sería bastante rico.

[santhy]

Pero si te diesen un dolar por cada respuesta que fuese eficiente en lo que se busca, no lo serías.
Lo que quiero decir es que tal vez la optimización sea muy pequeña, pero es evidente que existe.

Y hablando de situaciones prácticas, para poder crear un programa que analizase cierto tipo de archivos, tuve que crearme un generador de archivos similar a los que tendría que analizar (pues no tenía los originales).
El archivo tenía que pesar aproximadamente 600MB, y sí: es una cantidad de datos gigantesca para PHP. Pero gracias a que el iterador que creaba los bytes (un byte por iteración, y esto era necesario) era eficiente, y solo tenía dos condicionales (tenía que haber cierta probabilidad de que se incluyese una cadena de bytes concreta) pues el código era bastante eficiente, y en "poco tiempo" podía generar los archivos.
Igualmente, para analizar un archivo de 600MB y buscar series de cadenas para extraer sus contenidos, se necesita un código eficiente, pues cada parte entre dos cadenas es un bloque que puede pesar entre unos pocos KB y varios cientos de MB (que están en memoria hasta encontrar la cadena final).

Todo depende de lo que se necesite, pero hay situaciones en las que es necesario, enriqueplace.

Y la verdad es que veo necesario hacer un unset (o un vaciado $a = '') a la variable usada para guardar esos cientos de MB; pues si no, cada vez consumiría más RAM el script, pudiendo reutilizar las celdas con datos ya obsoletos.

[enriqueplace]

Pero si te diesen un dolar por cada respuesta que fuese eficiente en lo que se busca, no lo serías.

Si me dieran medio dolar por cada respuesta nacida del ego, temblaría Bill Gates.

Lo que quiero decir es que tal vez la optimización sea muy pequeña, pero es evidente que existe.

Como lo aclaré en los comentarios, "depende". En las situaciones normales este tipo de optimizaciones no producen ningún efecto apreciable, menos, encarar los sistemas desde "la optimización" y no desde "la funcionalidad".

Y hablando de situaciones prácticas, para poder crear un programa que analizase cierto tipo de archivos, tuve que crearme un generador de archivos similar a los que tendría que analizar (pues no tenía los originales).

Bueno, justamente, estas situaciones NO SON NORMALES ni TIPICAS ni PRÁCTICAS hacerlas con PHP, ya que no fue hecho para ello (aunque funcione y lo puedas hacer).

Todo depende de lo que se necesite, pero hay situaciones en las que es necesario, enriqueplace.

Justamente, esta situación no es el 99% de los casos para los cuales está pensado PHP.

Por lo tanto tu ejemplo queda descalificado en el contexto que estamos tratando.

PD: por las dudas lo aclaro, salimos con un tema de "POO, Clases y elementos estáticos", "optimización extrema" y ahora colocas un ejemplo de procesar en un batch un archivo de 600 Megas

Totalmente fuera de lugar.

[santhy]

No voy a seguir con esta discusión absurda y carente de fin, pues cada uno tiene su propia idea de ella y por lo visto ninguno piensa abandonarla. Por favor, disculpadme por la obviedad, pero os recordaré que 99% != 100%, y precisamente en un foro lo que se busca es información, y puede que atañe a ese 1% restante.

Por favor, atañémonos a contestar las preguntas iniciales.

En principio, como ya he comentado, el puntero $this no tendría que residir en el espacio reservado por Zend para el procesamiento de los métodos estáticos.

Pero la mayor optimización posible en PHP OO es crear el menor número de objetos posibles de cada clase.
En teoría es virtualmente igual de rápido el procesamiento de una clase completamente estática que una con UN objeto creado. (Tal vez haya algo más que procesar por parte de Zend, pero como dice enriqueplace, no se nota).

[mariano_donati]

Iniciado por enriqueplace

La pregunta es bastante improcedente... ¿estás pensando solo en optimizar de forma mecánica las clases? O sea, si la respuesta es que consume menos mejoria un "método de clase" (estático), de ahora en más, ¿harás todas las clases estáticas con métodos estáticos?

No tiene sentido la dirección de la pregunta.

Actualmente no estoy trabajando con php orientado a objetos, trabajo de forma procedimental. Y lo seguiré haciendo hasta que nos brinden un mecanismo con el que no haya que compilar cada clase/objeto por cada vez que se carga una página.
Mi pregunta apuntaba a que si las clases con métodos estáticos ocupaban menos espacio de memoria, o si se compilaban una sola vez para después ser utilizados en ese estado desde cualquier página que requiera el objeto o bien presentaba alguna diferencia en rendimiento marcada respecto a clases comúnes, entonces migraría a php orientado a objetos pero implementando esta solo con clases estáticas.
Gracias por sus respuestas. Siempre las encuentro muy útiles.
Saludos.

[GatorV]

Iniciado por mariano_donati

Actualmente no estoy trabajando con php orientado a objetos, trabajo de forma procedimental. Y lo seguiré haciendo hasta que nos brinden un mecanismo con el que no haya que compilar cada clase/objeto por cada vez que se carga una página.

Haz probado usar algún acelerador como IonCube Accelerator o Zend Optimizer?, estas herramientas guardan el estado compilado de las clases por lo que el interprete de PHP solo tiene que ejecutarlas. Lo que "acelera" la ejecucion ya que no hay que compilar.

Actualmente no creo que PHP tenga pensado implementar por defecto algun mecanismo de cache, por eso los hay terceros (y de la misma empresa que crea PHP, Zend).

Iniciado por mariano_donati

Mi pregunta apuntaba a que si las clases con métodos estáticos ocupaban menos espacio de memoria, o si se compilaban una sola vez para después ser utilizados en ese estado desde cualquier página que requiera el objeto o bien presentaba alguna diferencia en rendimiento marcada respecto a clases comúnes, entonces migraría a php orientado a objetos pero implementando esta solo con clases estáticas.

Usando, clases normales, estaticas, funciones etc. es igual, aunque uses el acelerador. PHP es un lenguaje "stateless" como todos los lenguajes web, asi es como esta implementado el protocolo HTTP, algunos lenguajes como Java usando algun framework, pueden persistir unos objetos, pero es el framework el encargado, no el lenguaje en si, si tu quieres persistir tu objeto por la sesion puedes usar $_SESSION.

Saludos

[enriqueplace]

Actualmente no estoy trabajando con php orientado a objetos, trabajo de forma procedimental. Y lo seguiré haciendo hasta que nos brinden un mecanismo con el que no haya que compilar cada clase/objeto por cada vez que se carga una página.

Mariano, sigue sin tener sentido lo que dices: "que no haya que compilar cada clase/objeto por cada vez que se cargar una página"... ¿que piensas que sucede en el lenguaje cuando es procedimental? Es lo mismo, para un lenguaje interpretado como PHP, hacer todo con funciones o con objetos no vas a encontrar diferencias a la hora de procesarlo.

Es falso pensar que por ser "procedimiental" tendrás más rendimiento que con objetos.

Mi pregunta apuntaba a que si las clases con métodos estáticos ocupaban menos espacio de memoria, o si se compilaban una sola vez para después ser utilizados en ese estado desde cualquier página que requiera el objeto

Tienes los conceptos equivocados, nuevamente, no hay diferencia entre paradigmas de programación cómo lo procesará PHP (más allá de interpretar la sintaxis y generar un "ejecutable en el aire"). Esto es "estado desconectado" ("stateless") y no existe normalmente nada del lado del servidor que persista entre páginas (a menos que uses un utilitario / herramienta para solventar esta situación).

Pero como dice, PHP en sí no hace nada de esto, y nuevamente, no hay diferencias sustanciales para el intérprete.

bien presentaba alguna diferencia en rendimiento marcada respecto a clases comúnes, entonces migraría a php orientado a objetos pero implementando esta solo con clases estáticas.

Bueno, saca esa idea de tu cabeza que no tiene sentido, estos paradigmas no fueron creados por el hecho de buscar optimización, es buscar nuevos caminos para resolver los problemas a la hora de implementar sistemas (y menos al hablar de "propiedades estáticas" se concibe pensar en hacer todo estático).

[enriqueplace]

Estimado GatorV, justo envié mi respuesta e inmediatamente vi que me actualizó y me mostró la tuya, y apuntábamos hacia lo mismo... casi como que mi respuesta quedó redundante

[GatorV]

No hay problema alguno, creo conocemos bastante de PHP para dar la misma respuesta.

Saludos

[califa010]

Aunque es algo dependiente de la implementación particular del lenguaje (del compilador, el intérprete, la máquina virtual o lo que sea...), en muchos de los lenguajes que tienen sintaxis de objetos (¿la mayoría?, ¿todos?), tanto los métodos estáticos como los de instancia son compartidos en tiempo de ejecución (Java, C#, C++, Actionscript, etc, etc). Es decir, hay una sóla copia del código de la función / método en memoria, por clase. Lo único que cambia es que a un método de instancia se le pasa un parámetro adicional, implícito (generalmente es el primero), que es la referencia / puntero a this (a partir de cual se puede acceder al estado del objeto, o sea, a las variables o propiedades de instancia).

En algunos lenguajes, este parámetro se declara incluso explícitamente (aunque no se pasa en la llamada); creo que así era en Python, donde el primer parámetro de un método es self, si no recuerdo mal (no estoy seguro de si el nombre es una palabra reservada o sólo una convención).

Pero fuera de eso, los métodos estáticos o de instancia son iguales en ese punto (más allá de las diferencias semáticas o conceptuales, a nivel del lenguaje).

Un ejemplo para ilustrar esto último (completamente inútil a los fines prácticos, por lo demás).

Código PHP:

  class Test {
 
    public $id;
    
    public function __construct($id) {
        $this->id = $id;
    }
    
    public static function testStatic($explicitThis) {
        return $explicitThis->id;
    }
    
    public function testInstance() {
        return $this->id;
    }
}
 
$a = new Test(1);
$b = new Test(2);
 
echo Test::testStatic($a) . ' - ' . $a->testInstance() . "<br>";
echo Test::testStatic($b) . ' - ' . $b->testInstance() . "<br>"; 
   

Saludos
Juan Pablo Califano