hola, vuelvo con mis preguntas sobre "rendimiento"
tengo una duda acerca de gameobject.transform y transform.gameobject
quiero tener acceso(quiero mover), via script, otro objeto que no es el que posee el script en cuestion, y estoy dudando cual es la manera mas optima(solo quiero cambiar la posicion)
deberia almacenar la referencia al GameObject o al Transform? unas veces lo hago de una forma y otras veces de la otra...
pongamos que quiero mover un "Cube":
que es mejor desde el punto de vista del rendimiento?
public GameObject miCubo;
//o es mejor:
public Transform miCuboTransform;
mi duda viene a raiz (como indica el titulo) de que el transform contiene el gameObject y el GameObject contiene el transform
??? *** ???
supongo que el transform.gameObject lo que hace es buscar a su "portador", osea, el GameObject...
entonces seria mejor solo usar como "ref" el transform?
...no tengo muy clara la gerarquia...
ah! y encima justo acabo de leer una respuesta de @FNP en el post "Sistema Guardar/Cargar" en "Scripting" en la que justo dice que hacer todo "publico" y pasar referencias via editor es "una de las cagadas mas grandes de Unity", lo se .... pero cada vez mas no hago mas que pasar referencias via editor.... es que esa "funcionalidad" simplifica tanto las cosas... jejeje... ten en cuenta que vengo del viejo "basic" y ahi no habia "objetos"... luego tambien toque algo de c++ y java, y ahi si aprendi sobre objetos y classes, (aunque no mucho del funcionamiento "interno") ...pero para mi el editor de unity es lo mas! (simplificando trabajo, no para el rendimiento)
ah, claro y entonces me surje otra duda, si pasar via editor es una "mierda" y usar "gameobject.find" es mas "mierda" todabia... como hago? un gameObject find en "void Start" y almaceno la "ref"?
???
Cita de: Igor date=1507988494ah! y encima justo acabo de leer una respuesta de @FNP en el post "Sistema Guardar/Cargar" en "Scripting" en la que justo dice que hacer todo "publico" y pasar referencias via editor es "una de las cagadas mas grandes de Unity", lo se .... pero cada vez mas no hago mas que pasar referencias via editor.... es que esa "funcionalidad" simplifica tanto las cosas... jejeje... ten en cuenta que vengo del viejo "basic" y ahi no habia "objetos"... luego tambien toque algo de c++ y java, y ahi si aprendi sobre objetos y classes, (aunque no mucho del funcionamiento "interno") ...pero para mi el editor de unity es lo mas! (simplificando trabajo, no para el rendimiento)
ah, claro y entonces me surje otra duda, si pasar via editor es una "mierda" y usar "gameobject.find" es mas "mierda" todabia... como hago? un gameObject find en "void Start" y almaceno la "ref"?
???
No seáis tan literales, una de las ventajas y principales características de la orientación a objetos es la encapsulación y todo lo que sean las variables publicas en una clase va en contra de eso, lo suyo es tener variables privadas y métodos públicos que gestionen esas variables privadas cuando son invocados y por lo tanto, las variables no se pueden tocar desde fuera de la clase, eso le da al sistema de clases robustez y estabilidad. Luego está la vida real y meter métodos para absolutamente todo es mayormente un coñazo, yo también vengo del basic con números de linea donde no había ni siquiera funciones y el control de flujo era a base de GOTO, así que se de lo que hablas, tampoco se trata de ser mas papista que el papa, por eso no me parece un problema guardar cosas en el PlayerPrefs
Lo del Find, SendMessage, etc. El problema es que es lento, no es que sea malo. Esta bien si no tienes que procesar 1000 objetos, con esa cifra ya te digo yo que la aplicación en un iPad, por ejemplo, va como el culo (probado usando el tag para buscar y activar y desactivar GameObjects).
Cita de: Igor date=1507988494tengo una duda acerca de gameobject.transform y transform.gameobject
GameObject siempre contiene
un único transform, por lo que mediante un transform podes obtener un único Gameobject, (relación bidireccional). Por eso siempre mi duda de que cachear el transform no tiene efecto, podrías llamar a "transform.position...." sin necesidad de cachearlo, incluso he hecho pruebas y no cambia
nada. Disitnto para otros componentes y los malditos GetComponent.
Cita de: Igor date=1507988494que es mejor desde el punto de vista del rendimiento?
cuando llamas a transform estas llamando la referencia del objeto transform (clase), cuando llamas a gameobject.transform estas llamando a la referencia del gameObject en cuestión, y de ahi su transform, supongo que no tenes casi nada de impacto, no estas "obteniendo componentes", estas simplemente llamando a un miembro obligatorio y que debe existir en dicho gameObject (sin Nullreferences). Yo lo pienso asi, si vas a administrar objetos, cambiarles nombre, borrarlos, crearlos, etc--> usa gameObjects, si vas a moverlos, rotarlos, enparentarlos, etc ---> usa transforms, además de que el código queda mucho mas legible.
Cita de: Igor date=1507988494ah, claro y entonces me surje otra duda, si pasar via editor es una "mierda" y usar "gameobject.find" es mas "mierda" todabia... como hago? un gameObject find en "void Start" y almaceno la "ref"?
Si vas a usar un FIND lo mejor es usarlo al principio, tene en cuenta que no encuentra objetos desactivados, (en un public GameObject sí los podes meter) y que depende del nombre, y de la cantidad de objetos en la escena, para mi tiene muchas más desventajas, pero si lo vas a usar lo mejor es hacerlo al principio.
Si tenes un buen esquema general no es necesario usar finds.
No creo que "pasar por editor" sea un mierda, hay cosas que desde el punto de vista del diseño/funcionalidad quedan mucho más cómodas referenciarlas por inspector.
"pasable por inspector" significa que unity serializa el campo de interés, generalmente los public ya están serializados, pero podes tener algo asi:
[SerializeField] GameObject GO;
y elegirlo por inspector también.
No va en rendimiento, el inspector ---> Diseño/Comodidad, esto es el foco. Aunque si conoces los Scriptable Object el número de los campos del inspector que uno normalmente usaba en sus objetos se reduce drásticamente. Esto si puede estar asociado a aspectos del rendimiento, sobre todo si en cada objeto estas teniendo la misma referencia a un prefab, una y otra vez, cuando podes tener una base de datos que ya la tenga.
Cita de: FNP date=1507992236yo también vengo del basic con números de linea donde no había ni siquiera funciones y el control de flujo era a base de GOTO,
jeje que recuerdos...
@gZone gracias, si, era como pensaba...
Cita de: lightbug date=1507992375si vas a administrar objetos, cambiarles nombre, borrarlos, crearlos, etc--> usa gameObjects, si vas a moverlos, rotarlos, enparentarlos, etc ---> usa transforms, además de que el código queda mucho mas legible.
lo solia hacer asi
gracias por la esplicacion
Wow, esa prueba me ha gustado, gracias!
Evidentemente si vas a tocar cosas relativas a posición o escala es mejor guardar el transform directamente y si vas a activar o desactivar es mejor el GameObject. De todas maneras, no creo que afecte demasiado al rendimiento utilizar uno y otro, ya que hacer gameObject.transform no creo que necesite demasiado procesamiento...
Hola @Igor, en realidad el titulo del tema esta equivocado ... ni el transform contiene el gameobject, ni el gameobject contiene el transform.
La clase GameObject puede referenciar al transform (que es el unico componente obligatorio) pero no es que lo tenga guardado; para que te hagas una idea, cuando haces gameobject.transform es como si fuera una manera simplificada de gameobject.GetComponent<Transform> y la prueba esta en que consume muchos mas recursos realizar gameobject.transform dentro del Update, por ejemplo para realizar un cambio de posicion, que no si guardas el transform en una variable y cambias la posicion mediante dicha variable.
Del mismo modo, el Transform tampoco contiene el GameObject ... lo que cualquier componente (Transform, Collider, o cualquier script realizado por ti) puede referenciar a su gameobject de manera similar a como sucede con la clase GameObject que puede acceder a su transform.
En resumen, que lo que tienen las clases GameObject y Transform son getters para referenciar a su transform o gameobject respectivamente, pero no los tienen almacenados de ningun modo.
Estos son los números de mi test:
Get Component : 5.81 ms
gameObject.transform: 4.30 ms
transform : 3.36 ms
transform (catched) : 2.32 ms
Asi que... a catchear siempre! y a evitar GetComponents en runtime
Cita de: lightbug date=1508014380Estos son los números de mi test:
Get Component : 5.81 ms
gameObject.transform: 4.30 ms
transform : 3.36 ms
transform (catched) : 2.32 ms
Asi que... a catchear siempre! y a evitar GetComponents en runtime
Uy, se acerca bastante a un GetComponent! No me lo esperaba.
Cita de: TheBullet date=1508019511Uy, se acerca bastante a un GetComponent! No me lo esperaba.
ah pero metele mas componentes y veras como sube por las nubes
"Es el alcalde , el que..."
Cita de: gZone date=1508024380De más rápido a más lento ...
Transform (cacheado) 1.374779
Transform 1.756747
gameObject.transform 2.152893
GetComponent 2.379752
gameObject.GetComponent 2.767935
* muy interesante hacer benchmarks, suelen aparecer sorpresas (sobre todo en comparativas entre plataformas)
Cita de: lightbug date=1508014380Estos son los números de mi test:
Get Component : 5.81 ms
gameObject.transform: 4.30 ms
transform : 3.36 ms
transform (catched) : 2.32 ms
Asi que... a catchear siempre! y a evitar GetComponents en runtime
muchas gracias, voy a modificar todos los scripts de mis proyectos, a "catchear" todo, jeje
o al menos todo lo que se "ejecute" varias veces(por existir multiples instancias del objeto, o por estar la "llamada" dentro de un "bucle" for o similar)
esta claro que lo mejor es almacenar todo en variables
quiza suba un poco el uso de memoria (en ejecucion)
y esto supongo que se aplica a todo....
porejemplo en un script de movimiento(que sea algo complejo) no haces mas que repetir por todos los lados "noseque * Time.deltaTime;"
supongo que sera mejor guardar deltaTime en un "float" y usar ese float para los calculos....
jejeje, podemos convertirnos en los "sheriffs"!!!
los programadores con el codigo mas rapido del oeste
Cita de: Igor date=1508072804porejemplo en un script de movimiento(que sea algo complejo) no haces mas que repetir por todos los lados "noseque * Time.deltaTime;"
supongo que sera mejor guardar deltaTime en un "float" y usar ese float para los calculos....
Interesante:
No catcheado: 1.24 ms
Catcheado: 0.25 ms
mmm Quiero entender que el guardar el valor de deltaTime en una variable para utilizarla es en plan ironico, medio en cachondeo ... pero como en los posts posteriores han continuado con la "broma" y en un tono serio, de hacer pruebas y tal, ya no se que pensar
en cualquier caso, siendo bien pensado y creyendo que era un chiste, mejor nos reiremos ... por lo menos que si alguien lee eso y no tiene muy claro lo que esta haciendo, no tenga el presentimiento de que esta correcto y se sienta tentado a hacerlo JAJAJAJA.
Cita de: Arthure date=1508080824mmm Quiero entender que el guardar el valor de deltaTime en una variable para utilizarla es en plan ironico, medio en cachondeo ... pero como en los posts posteriores han continuado con la "broma" y en un tono serio, de hacer pruebas y tal, ya no se que pensar
en cualquier caso, siendo bien pensado y creyendo que era un chiste, mejor nos reiremos ... por lo menos que si alguien lee eso y no tiene muy claro lo que esta haciendo, no tenga el presentimiento de que esta correcto y se sienta tentado a hacerlo JAJAJAJA.
???
entonces es broma??? estaba "catcheando" todos los transforms y deltaTimes ...en sitios donde estaban "repetidos" varias veces...
ala, me habeis hecho dudar, y he hecho yo mismo la prueba, SI, es bastante mas rapido guardar el valor de "deltaTime" en un float, llamar todo el rato a "Time.deltaTime" es mas lento
pero si vas a usar "Time.deltaTime" pocas veces quizas no sea muy conveniente, ya que tienes "crear" un float y almacenar el valor ahi, y eso tambien requiere com***cion
Bueno supongo que os referís a asignar a un float el Time.deltaTime al principio del Update y después utilizar el float donde se necesite en ese Update para no llamar repetidas veces el deltaTime no? Porqué el deltaTime cambia a cada frame...
Quizás estáis buscando optimizar en exceso, no se hasta que punto se puede notar eso en equipos modernos, muchos deltaTIme se tendrían que utilizar...
si lo que quieren es ahorrar mucho tiempo eliminen todos los logs de consola, o ponganlos dentro de una condicion para desactivarlos cuando el producto este listo
@TheBullet, si, es guardar el valor al principio del Update, pero solo en caso de que se valla a hacer un uso excesivo, porejemplo yo lo estoy poniendo(ahora mismo) en scripts que pasan de seis usos de Time.deltaTime,
y tambien en sitios donde accedo mucho al transform estoy "catcheandolo"
porejemplo un array de objetos contra la "pos" del player, catcheo la pos del player, y la uso en el bucle(for i=0;...) que comprueba cada elemento del array, si tienes 100 elementos en el array tendrias que "llamar" cien veces al trasform.position para chekearlo con array.transform.position
y incluso si usaria mucho dentro del bucle el transform de cada elemento, quizas tambien catchearia eso...
jejeje
ah! ya que estamos de tests, he hecho test de Random.Range(int,int) contra System.Random.Next(int,int)
gana el random de Unity, el del System es mas lento
Cita de: TheBullet date=1508086562Quizás estáis buscando optimizar en exceso, no se hasta que punto se puede notar eso en equipos modernos, muchos deltaTIme se tendrían que utilizar...
sí, es cierto, quizas sea demasiado para unos pedorros cuatro o cinco Time.deltaTime's y sobretodo teniendo en cuenta los tiempos de los demas procesos del frame, aunque hacerlo no estaría demás.
@TheBullet es que para mi cachear con el objetivo de optimizar rendimiento, por lo menos en lo que se refiere a la funcion Update, solo tiene sentido si asignas el valor a la variable dentro de las funciones Start o Awake. Por ese motivo pensaba que era una broma ... porque no le encontraba ningun sentido puesto que el valor de deltaTime cambia en cada frame.
Incluso aunque me dijeran que guardando el valor de deltaTime iria un 75% mas rapido ... lo encontraria una tonteria: si a 1.000.000 le quitas el 75% la diferencia es abismal pero si a 0 le quitas el 75% te quedas igual. No comparemos los recursos que consume GetComponent, por ejemplo, con los que consume Time.deltaTime.
Para que tuviera un impacto notable el guardar deltaTime dentro de una variable se deberia de utilizar tal numero de veces dentro del Update que, aun sin saber como es el codigo (sin necesidad de verlo), me atreveria a asegurar que el menor de los problemas seria el uso de deltaTime.
Otra razon por las que un programador podria guardar cierto valor en una variable es para darle un nombre descriptivo, consiguiendo asi un codigo mas facil de leer ... por ejemplo, si tienes un circulo cuyo radio fuera de 5 unidades, en el caso de que tuvieras que trabajar con el area se crearia una variable llamada area_circulo = radio * 3.14; indistintamente de que lo fueras a utilizar 1 o 20 veces ... pero no por rendimiento, sino porque haras un codigo mas facil de leer. Pero tampoco es el caso de deltaTime porque cualquiera que lea esa palabra ya sabe lo que significa.
Ahora a nivel personal, a mi me causa sonrojo como poco el observar que se quiera optimizar en exceso incluso guardando el valor de deltaTime en una variable ... pero al mismo tiempo se vea continuamente fragmentos de codigo donde se utilizan GetComponent o Debug.Log como si los regalasen con las pipas
Yo también lo encuentro pasarse, quizás para móviles es más útil... También dependerá del caso, si tienes un for o un while que utilizan una posición o el time.delta time a cada vuelta quizás será mejor guardarlo, pero para uso habitual lo veo excesivo.
Cita de: TheBullet date=1508134760Yo también lo encuentro pasarse, quizás para móviles es más útil... También dependerá del caso, si tienes un for o un while que utilizan una posición o el time.delta time a cada vuelta quizás será mejor guardarlo, pero para uso habitual lo veo excesivo.
Incluso aunque la funcion Update contenga un bucle for y que tuviera que recorrer 10.000 de objetos ... sin necesidad de ver el codigo, como habia dicho anteriormente, me atreveria a decir que el menor de los problemas es el uso de deltaTime.
Pongamos por ejemplo que nuestro personaje avance 1 unidad por cada enemigo que haya dentro de un rango de X unidades en un momento dado, es decir en el frame en cuestion. A continuacion pongo dos codigos que hacen exactamente lo mismo ...
EnemigoControlador [] enemigos;
float distancia_minima_reaccion;
private void Update () {
foreach (EnemigoControlador enemigo in this.enemigos) {
if (personaje.posicion - enemigo.posicion < distancia_minima_reaccion) {
personaje.posicion = personaje.posicion + distancia_recorrer * Time.deltaTime;
}
}
}
EnemigoControlador [] enemigos;
float distancia_minima_reaccion;
private void Update () {
int enemigos_dentro_rango = 0;
foreach (EnemigoControlador enemigo in this.enemigos) {
if (personaje.posicion - enemigo.posicion < distancia_minima_reaccion) {
enemigos_dentro_rango += 1;
}
}
personaje.posicion = personaje.posicion + (distancia_recorrer * enemigos_dentro_rango) * Time.deltaTime;
}
Ambos codigos hacen exactamente lo mismo, aunque lo que hacen sea una chorrada ... la diferencia es que en el primero utilizas deltaTime un numero indeterminado de veces (hasta un maximo igual al numero de enemigos) y en el segundo caso solo utilizaras deltaTime en una unica ocasion, indistintamente al numero de enemigos.
Como decia, si se utiliza deltaTime 10 - 20 - 30 ... veces en una sola funcion Update, no hace falta ver el codigo para saber que el menor de los problemas es el deltaTime. Programar con la mentalidad de optimizar el codigo, junto con la de hacer un codigo facil de leer, es la mejor practica y lo mas sensato (y eso lo dira cualquier programador del mundo) ... pero para optimizar hay que saber lo que se hace y no solo ponerse a quitar cosas a punta pala.
Cita de: Arthure date=1508134091Incluso aunque me dijeran que guardando el valor de deltaTime iria un 75% mas rapido ... lo encontraria una tonteria: si a 1.000.000 le quitas el 75% la diferencia es abismal pero si a 0 le quitas el 75% te quedas igual. No comparemos los recursos que consume GetComponent, por ejemplo, con los que consume Time.deltaTime.
Es cierto, pero no creo que estas pruebas se hayan realizado, para "ponerse en contra" de los Time.deltaTime, simplemente se desmostró lo obvio. Además, un factor de mejora es un factor de mejora, independientemente de la cantidad de llamadas que tengas, distinto es hablar de una mejora general (específica de la aplicación), ya que, como bien decís, existen otros factores de mayor peso que deben ganar mayor atención que algunos simples Time.deltaTime, sería una tontería "optimizar" partiendo de esto, pero si se diera el caso que "estos tiempos"(dT) sean comparables con los "otros tiempos"(resto del código, monoB, graficos, audio, IA, etc), ya sea porque uno desea llamar 10 trillones de veces a un Time.deltaTime (vaya uno a saber porqué) la mejora general que implica la mejora del dT es, como bien decís, abismal. Claro, esta situación casi nunca se da y almacenar el dT se puede ignorar completamente.
Cita de: lightbug date=1508164419Es cierto, pero no creo que estas pruebas se hayan realizado, para "ponerse en contra" de los Time.deltaTime, simplemente se desmostró lo obvio. Además, un factor de mejora es un factor de mejora, independientemente de la cantidad de llamadas que tengas, distinto es hablar de una mejora general (específica de la aplicación), ya que, como bien decís, existen otros factores de mayor peso que deben ganar mayor atención que algunos simples Time.deltaTime, sería una tontería "optimizar" partiendo de esto, pero si se diera el caso que "estos tiempos"(dT) sean comparables con los "otros tiempos"(resto del código, monoB, graficos, audio, IA, etc), ya sea porque uno desea llamar 10 trillones de veces a un Time.deltaTime (vaya uno a saber porqué) la mejora general que implica la mejora del dT es, como bien decís, abismal. Claro, esta situación casi nunca se da y almacenar el dT se puede ignorar completamente.
Tienes razon en que si vas a utilizar 10 trillones de veces Time.deltaTime dentro del Update se notaria la diferencia en comparacion a guardar el valor una variable ... pero en ese supuesto caso, como decia (y sin necesidad de verlo), estaremos de acuerdo en que tendrias una mierda de codigo xDDD
Pero olvidemonos de utilizarlo 10 trillones de veces ...
si eres capaz de pensar en un codigo factible para la funcion Update donde se utilice un minimo de 5 veces (una miseria !!!) el Time.deltaTime y no sea capaz de optimizarte el codigo sin necesidad de almacenar deltatime en una variable, para mi sinceramente estarias en un pedestal. (puedes tomarlo como un reto personal, que es buena manera de practicar)
Como ejemplo utilice un caso que contenia un bucle con un indeterminado numero de elementos (podian ser 1 o 10.000) y aun asi el deltatime, optimizando el codigo, solo se utiliza una sola vez. Por eso me refiero, a que si tienes un codigo donde utilizas el deltatime un gran numero de veces, es que no tienes un codigo muy optimizado ... y cuando se habla de optimizar, en lo primero que se deberia pensar es en el codigo en su conjunto.
P.D. para mi, el numero maximo necesario que aparece deltatime en una funcion Update (sabiendo para lo que se utiliza dicho valor) es dos veces ... Si aparece mas veces, señal de que algo esta fallando en el planteamiento del codigo.
Cita de: Arthure date=1508167270estaremos de acuerdo en que tendrias una mierda de codigo xDDD
Totalmente, ya el problema sería otro. Pero bueno, a modo de exagerar un poco y encontrarle una aplicación forzada a todo este asunto.
Cita de: Arthure date=1508167270P.D. para mi, el numero maximo necesario que aparece deltatime en una funcion Update (sabiendo para lo que se utiliza dicho valor) es dos veces ... Si aparece mas veces, señal de que algo esta fallando en el planteamiento del codigo.
También de acuerdo. Es muy raro tener mas de un dT. En mis scripts (character controllers 2D/3D o multiples objetos rotando/desplazándose) nunca me paso de uno, siempre la operacion vectorial asociada al dT está al final de todo, o cerca (en el character controller 2D).
bueno si, esta claro que con el caso de deltaTime poco vamos a ganar de rendimiento... es mas bien un ejemplo para entender que es mejor guardar en una variable que llamar a la misma classe varias veces, o porejemplo catchear componentes en void Start para luego no tener que usar getComponent... ese tipo de cosas(abalorios, bagatelas...)
igual deltaTime no era el mejor ejemplo ya es mas rapida que mucho otros metodos que si que consumen mas tiempo, ....y "optimizar" los deltatimes quizas reduzca el tiempo total del frame en un 0.0000001%...
...pero si vas juntando granitos de arena....
postdata: no he podido resistirme a poner lo de abalorios y bagatelas