Diferencia entre tener varios plugins separados o en uno solo

[LJAV]

Hola,
Por ejemplo, en vez de tener 40 plugins instalados, meter todos los plugins en 1 solo(o la mayoría en 1 solo). ¿Mejora el rendimiento? ¿es lo mismo? ¿que diferencia tiene?

[Alejandro]

No creo que tenga alguna diferencia igual pesara lo mismo si tienen el mismo contendió.

[Destro]

depende, por ejemplo en el ZP
muchos plugins para el ZP hookean funciones que se llaman decenas y cientos de veces por segundo, y en esas funciones suelen hacer llamadas a natives del ZPcore (zp_is_user_zombie etc..)
teniendo todo en un solo plugin bajas bastante el consumo de cpu en esos casos


personalmente combino una de las ventajas de tener plugins separados que es la de facilitar el mantenimiento

[Chamo.]

depende, por ejemplo en el ZP
muchos plugins para el ZP hookean funciones que se llaman decenas y cientos de veces por segundo, y en esas funciones suelen hacer llamadas a natives del ZPcore (zp_is_user_zombie etc..)
teniendo todo en un solo plugin bajas bastante el consumo de cpu en esos casos


personalmente combino una de las ventajas de tener plugins separados que es la de facilitar el mantenimiento

Yo estoy combinando ambas formas.

Divido el código en diferentes archivos fuentes, y los enlazo en un solo addon.

Así es sencillo customizar el MOD, a la ves que me evito re-utilizar funciones hookeadas por el plugin central (básicamente lo veo como un proyecto de c/c++, quizás para algunos sea estúpido o hasta no recomendado pero a mi me basta y sobra por el momento ).

[warrior]

Un código con una cantidad de 35.000 líneas, influye en algo?, o ustedes destro y/o chamo solo lo hacen por comodidad?, buscar más sencillo cierta parte del código?

[kikizon2]

Como ya explicaron arriba, la unica forma en que te puede optimizar el consumo en el server, es que se llamen muchas forwards pesadas en diferentes plugins, si lo juntas solo en uno, obviamente tendras una mejora, como ejemplo te digo los extra items que funcionan como armas "nuevas" en los zombie plague.

[warrior]

Ok ok, me habia perdido con lo de dividir al plugin JAJA

[Chamo.]

Ok ok, me habia perdido con lo de dividir al plugin JAJA

Todos esos archivos los enlazo en zr2.c (si, se que no es un programa en C, pero me gusta como se ve), y al compilarlo obtengo el addon completo.

Con eso te ahorras por un lado uso (medio)excesivo del CPU, y por otro lado puedes modificar el código fácilmente (mucho mas si lo documentas).

[cLAANS]

Ok ok, me habia perdido con lo de dividir al plugin JAJA

Con eso te ahorras por un lado uso (medio)excesivo del CPU, y por otro lado puedes modificar el código fácilmente (mucho mas si lo documentas).

Hay que tener ganas de documentar un .sma

Saludos,
cLAANS.-

[matrix123]

Fuera de que ya comentaron todo, quiero dar mi simple opinion

Depende de lo que vayas a hacer te conviene todo en 1 (o más) plugin/s, si hablamos de un MOD (que usualmente son codigos grandes) ademas de optimización/rendimiento tambien te conviene ver que tan legible es el codigo, si lo separas (como te mostró Destro) cuando quieras editar te va a resultar mucho más facil, si hablamos de un codigo de por ejemplo 800 lineas, te conviene en un solo plugin (obviamente depende lo que quieras hacer, como bien dije arriba)

[Hinami]

Opino lo mismo que destro, si el plugin no tiene mayor consumo separados te va mejor por si necesitas editarlos no tienes que buscarlos dentro de tanto código, ahora si son forwards que se llaman muchas veces es mejor en uno solo.

Es como en otros lenguajes cuando aprendes POO, utilizas clases para optimizar y hacer un mejor consumo. ( o eso creo yo xdxd )

[Chamo.]

Ok ok, me habia perdido con lo de dividir al plugin JAJA

Con eso te ahorras por un lado uso (medio)excesivo del CPU, y por otro lado puedes modificar el código fácilmente (mucho mas si lo documentas).

Hay que tener ganas de documentar un .sma

Saludos,
cLAANS.-

PD: Ya ven porque es importante documentar todo, ahora no entiendo un pin** jaja.

Es preferible perder unos minutos documentandolo todo, que perder 1 hora tratando de entender qué *** hiciste, para luego hacer un solo cambio (claro, lo digo desde el punto de vista de customizar un proyecto tiempooooo después)

[fearAR]

JAJAJA exacto

Respecto de lo que dicen, yo no se como funciona el Addons de AmxMod X para estos casos pero quizas pueda aportar algo.

Lo de repartir las diferentes funcionalidades y modulos de un proyecto en diferentes .sma obviamente que aporta reutilizacion y legibilidad mientras tambien se respeten reglas de codigo limpio, como la correspondencia de una funcion con lo que hace sin sobrecargar de otras funcionalidades que no son descriptas por su nombre por ejemplo. La buena tabulación, el buen nombramiento de las variables, etc.

Con respecto al consumo como dije desconozco, pero en el caso de ejecutables por si solos al momento de ser "corridos" se reserva en memoria tres espacios/segmentos.

De codigo
Datos
BSS
Stack
Heap

Justamente en el de codigo o segmento de texto, es donde se almacenan las correspondientes instrucciones en assembler para ser interpretadas por la maquina al momento de la ejecucion y las funciones se llaman por punteros a aquellas direcciones hasta ser devueltas por "ret" a la memoria almacenada en algunas de las flags del procesador.

Por ello lo que creo que sucede es que al momento de compilar, el compilador se encarga (previo a la ejecucion) de aglutinar todo el codigo dentro del mismo paquete de instrucciones ".amxx" para luego en su conjunto reservar memoria.


O quizas todos los ficheros .amxx corresponden al mismo segmento.

Desconozco pero aporto la info.

[Destro]

con lo que dijo fearAR me acorde de algunos "mitos"

- Poner las funciones que mas usas al principio del plugin (falso)
Algunos creían que cada vez que llaman a una forward se tiene que hacer un loop entre todas las funciones publicas y cuando coincida del nombre se llama a la función. Pero este paso se hace al registrar la forward, una vez que tenes el puntero de la función no importa si el plugin tiene 10 o 1000000 funciones, es igual de rápido.

- Hardcodear funciones para el manejo de string es mas rápido que natives (falso)
Ver el spoiler, como se sabia que ese método era mas eficiente que usar las natives equal/equali, hay gente que empezó a hardcodear funciones imitando a natives existentes por creer que era mas eficiente. Esto puede ser cierto cuando el string tiene menos de 5, pero con mas caracteres escala pésimo.

Se puede comparar un string conocido o con un formato conocido mucho mas eficientemente de esta forma:

Código PHP:

// Lista de string conocidos para comprobar: "", "hola", "hora", "otro mas"
if(!szExample[0])
    // ""

if(szExample[0] == 'h' && szExample[2] == 'l')
   // "hola"

if(szExample[0] == 'h' && szExample[2] == 'r')
   // "hora"

// "otro mas" 


- Usar Bitwise como bool(true/false/0/1) es mas rápido (falso)
Para mi esto es lo peor, no soporto ver a plugins usando bitwise en todos lados :S
Aunque la diferencia es mínima, esa diferencia esta a favor del uso "normal" de variables. Es util para usarlo en lugares específicos, pero ser tan hdp para usarlo en todos los bools del plugin te rompe mucho las bolas .

[Chamo.]

con lo que dijo fearAR me acorde de algunos "mitos"

- Poner las funciones que mas usas al principio del plugin (falso)
Algunos creían que cada vez que llaman a una forward se tiene que hacer un loop entre todas las funciones publicas y cuando coincida del nombre se llama a la función. Pero este paso se hace al registrar la forward, una vez que tenes el puntero de la función no importa si el plugin tiene 10 o 1000000 funciones, es igual de rápido.

- Hardcodear funciones para el manejo de string es mas rápido que natives (falso)
Ver el spoiler, como se sabia que ese método era mas eficiente que usar las natives equal/equali, hay gente que empezó a hardcodear funciones imitando a natives existentes por creer que era mas eficiente. Esto puede ser cierto cuando el string tiene menos de 5, pero con mas caracteres escala pésimo.

Se puede comparar un string conocido o con un formato conocido mucho mas eficientemente de esta forma:

Código PHP:

// Lista de string conocidos para comprobar: "", "hola", "hora", "otro mas"
if(!szExample[0])
    // ""

if(szExample[0] == 'h' && szExample[2] == 'l')
   // "hola"

if(szExample[0] == 'h' && szExample[2] == 'r')
   // "hora"

// "otro mas" 


- Usar Bitwise como bool(true/false/0/1) es mas rápido (falso)
Para mi esto es lo peor, no soporto ver a plugins usando bitwise en todos lados :S
Aunque la diferencia es mínima, esa diferencia esta a favor del uso "normal" de variables. Es util para usarlo en lugares específicos, pero ser tan hdp para usarlo en todos los bools del plugin te rompe mucho las bolas .

Se que no tiene nada que ver con lo que comentaste, pero también quería añadir algo, relacionado con este comentario:.

depende, por ejemplo en el ZP
muchos plugins para el ZP hookean funciones que se llaman decenas y cientos de veces por segundo, y en esas funciones suelen hacer llamadas a natives del ZPcore (zp_is_user_zombie etc..)
teniendo todo en un solo plugin bajas bastante el consumo de cpu en esos casos

Personalmente opino que una forma eficiente de solucionar eso, es enviar un update a todos los 3rd-party plugins con la información del jugador.

Así se pueden evitar situaciones como esta:

Código PHP:

for (new player = 1; player <= get_maxplayers(); player++)
{
    if (!is_user_alive(player) || zp_get_user_zombie(player));
    
    zp_set_user_zombie(player);
    
    // etc...
}