Todo fantástico lo que dices. Es cierto, el dynamic dispatch es un poco más lento que el static dispatch.
Ahora bien, si declaras variables dentro de un loop y les defines valores, también se vuelve más lento el loop que si las variables las declaras afuera. Pasa de 0.5 ns a 0.8 ns, imperceptible para cualquier usuario. El único problema de esto es que se contamina el espacio de nombres (name space pollution). Como regla general, cuando hay que elegir entre correctitud o velocidad, es mejor ejegir correctitud y luego agregarle velocidad. En 1994 también había revuelo porque las llamadas dinámicas en C++ demoraban el doble que las llamadas estáticas. Entonces la recomendación era hacer todos los métodos "non virtual" a menos que se fueran a redefinir en alguna subclase. Para los que disfruten de los nombres antiguos, su nombre era Virtual Method Table (VMT) y era una de las razones por la que la herencia múltiple nunca estaba bien implementada, en otras palabras, la VMT era un hack inteligente que no era capaz de soportar la herencia múltiple. El problema de fondo de crear métodos no virtuales, como era la recomendación en ese tiempo, era que inevitablemente los métodos antiguos que eran "non virtual" debían convertirse en virtuales luego cuando aplicabas los mismos principios de la orientacion a objetos una y otra vez... Pero se requería recompilar la jerarquía completa de clases (sólo un par de cientos) y eso tomaba toda la tarde, lo cual eventualmente tomaba todas las tardes de un mes y tomabas la decisión inteligente de convertir todos tus métodos en virtuales, contrariando a tus compañeros de trabajo menos inteligentes que pensaban que la clave de la optimización es "optimizarlo todo" (la lección de los cursos de optimización de la universidad es que no puedes optimizar globalmente y localmente al mismo tiempo, las soluciones son completamente diferentes, y en general lo que uno busca son las soluciones globales, de modo que las optimizaciones locales se pueden ignorar con confianza incluso para modelos de juguete). Finalmente la discusión respecto de si volver todos los métodos virtuales o no era irrelevante porque todo el tiempo de ejecución en memoria de una petición tomaba menos de 10 ms, mientras que tan sólo una lectura de disco o una consulta de bases de datos o un requerimiento de red tomaba más de 10 ms, de modo que valía la pena minimizar estas útlimas que andarse preocupando por optimizaciones irrelevantes. Esto es verdad hasta el día de hoy (tanto en Smalltalk como en Java todos los métodos son virtuales y no tiene efecto notable sobre el desempeño, lo que importa es optimizar globalmente la aplicación una vez que está terminada). En otras palabras, aún si logras convertir el costo de 0.8 ns a 0 ns, segirá demorando lo mismo desde el punto de vista del usuario. Las optimizaciones, por lo tanto, tienen más que ver con escribir código que sea obviamente correcto, y dejar las optimizaciones en bibliiotecas, de manera de asegurarse que cumplan un amplio espectro de necesidades de usuario y no sean dependiendo del "modelo del mundo" proyectado por el usario en ese momento, que como todos sabemos se encuentra siempre en evolución constante (por no decir que está permanentemente equivocado). Saludos, Guillermo. 2009/9/18 andres <[email protected]> > > Por algun motivo se mamo el link (puede que sea porque me habia olvidado > el título :P). Va la nueva url: > > http://becoming.blogs.clubsmalltalk.org/2009/09/tesis-wilkinson/ > > Saludos, > Andrés > > > andres escribió: > > Luego de mi pedido, cumplo en informar que la tesis de Hernán está on > line: > > > > http://becoming.blogs.clubsmalltalk.org/2009/09/44/ > > > > Saludos, > > Andrés > > > > Juan escribió: > >> hola gente , lea > >> > >>> Así que bueno, la duda concreta viene por ese lado, ¿por qué se hace > así (como >explicaron) y no como se le ocurrió a mi compañero? Lo primero > que se me viene a la >mente es el caso de la redefinición de métodos, o > cuando se utiliza super, pero no sé si >en todos los lenguajes OO es igual. > >> El caso de super en st es que el method lookup comienza en la clase > >> superior no en la clase del receptor. > >> > >> si tenes una jerarquia A- >B > >> > >> A super clase de B > >> > >> y ambas implementan . por ej name ( reponde el nombre de la clase como > symbol.). > >> > >> una instancia de A que recibe name responde #A > >> una instancia de B responderia #B > >> pero una instancia de A que llame a name con super, > >> super name > >> responderia #B. > >> salu2 > >> mdc > >> > >> > >> > >> > >> > >> 2009/9/8 GallegO <[email protected]>: > >>> El 8 de septiembre de 2009 18:15, Leandro Martín Malsam > >>> <[email protected]> escribió: > >>>> Así que bueno, la duda concreta viene por ese lado, ¿por qué se hace > así > >>>> (como explicaron) y no como se le ocurrió a mi compañero? Lo primero > que se > >>>> me viene a la mente es el caso de la redefinición de métodos, o cuando > se > >>>> utiliza super, pero no sé si en todos los lenguajes OO es igual. > >>>> > >>>> Salu2 > >>>> > >>>> Lea > >>>> > >>> Ahora que leo esto que planteas me acorde que en VisualSmalltalk se > puede > >>> hacer eso, si uno quisiera hacer la prueba, usando Object>>addBehavior: > y > >>> experimentar con esas cosas. Lo bueno es que para probar, como es > basado en > >>> instancias tambien te sirve para comparar entre comportamientos de > algunas > >>> instancias y de otras de la misma clase. > >>> Incluso podrias cambiar el MethodDictionary completamente, mientras tu > >>> sistema funciona. > >>> > >>> Las diferencias con c++ y java se pueden ver bien resumidas aqui: > >>> http://en.wikipedia.org/wiki/Dynamic_dispatch > >>> Ojo que con respecto a Smalltalk habla un poco de más y al pedo, sin > sentido > >>> :) > >>> > >>> Saludos > >>> GallegO > >>> > >>> > > > > > > > > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
