Entradas

Mostrando entradas de agosto, 2009

El navegador que espero

Imagen
Haciendo un break entre los post de los test realizados creo necesario soñar un poco y ponerme a imaginar qué navegador me gustaría tener uniendo todas las cosas que me gustan de los actuales. De Firefox me gustaría tener esa gran comunidad que posee con el sinfín de complementos y que estos no penalizaran el rendimiento del mismo. Me gusta también que puedas mover las pestañas entre ventanas o arrastrarlas para crear nuevas. De Internet Explorer me quedaría con la independencia total que tienen una pestaña de otra, también echo por Google Chrome pero a mi modo de ver no tan magistralmente. Me gusta mucho que cuando abres una nueva pestaña a partir de otra tengan el mismo color, ese pequeño detalle me encanta. Y me quedo con su gestión de descargas, es la de toda la vida, a la que estoy acostumbrado, ni por mucho la mejor pero si la que necesito. De Chrome me quedo con su barra de direcciones multiuso, muy pero que muy útil, me gusta su diseño y su página de inicio de la versió

Celtic Kane Javascript Benchmark

Imagen
De los test específicos realizados este es el que me ha aportado unos datos más relevantes además de ser de un grupo independiente no asociado a ningún motor JavaScript de ningún navegador, por tanto la imparcialidad está, como mínimo, más garantizada. La ventaja de este test es que prueba los elementos más básicos de JavaScript y además AJAX, con el cual me llevé la gran sorpresa pues si la prueba de AJAX no se hubiera realizado Safari sería el glorioso vencedor pero por esta  prueba es, aunque suene increíble, el aplastado perdedor, incluso por debajo –y ni yo me lo creo- de Internet Explorer 8. Las pruebas se realizan sobre la mayoría de los objetos de JavaScript: Arrays, Date, Math, RegEx, String; además incluye pruebas sobre el DOM, el manejo de errores y la conflictiva declaración de AJAX. Los resultados son los siguientes: Si hubiésemos eliminado la prueba de AJAX los resultados hubiesen sido totalmente distintos, veamos: El test lo podéis realizar desde aquí ,

V8 Benchmark Suite

Imagen
Si el anterior test estaba diseñado por los miembros de WebKit este está diseñado por los miembros de Google Chrome y más concretamente de su nuevo y reluciente motor JavaScript V8, por lo cual está de sobra decir quien se lleva la palma en el mismo. Este test es al contrario de los demás, el que alcance la mayor puntuación es el mejor. La suite V8 consta de 7 pruebas independientes escritas por diferentes programadores y en ellas se basan para optimizar Google Chrome, las pruebas miden desde el propio Kernel del SO hasta encriptación, expresiones regulares y manipulación de datos. La última versión la podemos encontrar aquí junto con una explicación breve (en inglés) y un histórico de las mismas. Los resultados arrojados fueron los siguientes: Recordad que en este test mientras más grande mejor, o sea que aquí el tamaño SI importa. Como aclaración decir que al salir la versión 4 de Safari se dijo que era la más rápida y luego de pasar este test quedó por detrás de Chro

SunSpider WebKit Benchmark

Imagen
El test SunSpider realiza una serie de pruebas sobre el navegador para saber el tiempo que le toma para procesar ciertas instrucciones, las cuales abarcan: renderizado 3D; acceso a arrays, propiedades de objetos y variables; procesos matemáticos con enteros y punto flotante; control de flujo (bucles, recursión, condicionales); encriptado; performance de objetos "date"; expresiones regulares y tratamiento de cadenas. La fiabilidad de este test ha surgido porque realiza un ciclo de 5 repeticiones de cada prueba y hace una media estadística de estas mediciones además de brindar el porcentaje de error de las mismas. Es un test creado por los desarrolladores de Webkit el motor de renderizado de Safari y también Chrome lo utilizó en sus diseños anteriores por lo que su V8 está basado en Webkit. Está de más decir que es lógico que estos dos navegadores salgan bien parados en esta comparativa. Veamos los resultados: Y esta es la tabla comparativa según los bloques de prueba

Test Acid3

Imagen
El test Acid3 pone a prueba lo navegadores con los estándares web, especialmente los de DOM y ECMAScript. La parte principal de Acid3 esta escrita en ECMAScript (JavaScript), y consiste de 100 sub-pruebas divididas en seis grupos, llamados "buckets", más cuatro pruebas especiales. El único requerimiento de la prueba es que el navegador tenga la configuración de forma predeterminada. El renderizado final debe mostrar un 100/100 y además no sólo debe ser idéntico al de referencia sino que además la animación debe ser fluida (la prueba en teoría no debe tomar más de 33 milisegundos). Esto son datos sacados de la wikipedia sobre este test, ahora veamos los resultados: Los Navegadores Safari, Opera y Chrome obtuvieron el 100 % la única diferencia fue el tiempo de carga del test siendo en el Safari el más rápido de estos y Chrome el más rezagado, aunque la diferencia no supera los 5 milisegundos.   Nuestro amigo Firefox en su versión 3.6 alcanzó la no despreciable cifra d

Pruebas de velocidad en navegadores

Imagen
Desde hace unos días vengo aprovechando en casa para ir escribiendo un pequeño manual sobre nuevas tendencias en JavaScript y por supuesto en él he tenido que hablar de los navegadores y sus respectivos motores de renderizado y motores de JavaScript. Como soy un poco quisquilloso y no se me da fiarme de lo que ponen en las web sobre las ventajas de uno u otro, decidí crearme mi propio sistema para ver, después de varias pruebas, cual era el realmente más rápido de todos. En fin que manos a la obra me puse a googlear y descubrí que existen unos cuantos test para los navegadores y personalmente elegí solo 6, en este post pondré las condiciones básicas en que desarrollé cada una de las pruebas las cuales iré explicando en un post individual y al final pondré unas conclusiones. Equipo Utilizado El ordenador dónde se realizaron las 7 pruebas es un Intel Core 2 Quad a 2,4GHZ con 4 GB de RAM DDR2 bajo el innovador Windows 7 Ultimate en la versión de 64 bits.   Navegadores Testead

PHP como lenguaje orientado a objetos

Imagen
Realmente entre los lenguajes web PHP me parece el más robusto o al menos el más versátil de todos, pero gustos colores y no es el tema que me ocupa, pero como lenguaje orientado a objetos está muy verde aún. Es cierto que implementa la herencia múltiple de interfaces y la herencia simple de clases, tipos de datos public, protected, private y métodos abstractos. Es un lenguaje que va por muy buen camino pero creo que se ha estancado en esto, y lo digo porque en las nuevas especificaciones de PHP 6 no veo nada sobre polimorfismo (capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en función de los parámetros utilizados durante su invocación. Un objeto polimórfico es una entidad que puede contener valores de diferentes tipos durante la ejecución del programa) y menos sobre herencia múltiple de clases . La herencia múltiple la trato en el post anterior y entiendo que tal vez no se implemente por problemas conceptuales que nunca entenderé. sobre el

Herencia Múltiple ¿por qué no?

Imagen
El tema de la herencia múltiple más que el poder implementarlo es el ponerse de acuerdo en cuanto a si hacerlo o no, de ahí que ¿útil o inútil? he ahí el dilema. Yo soy partidario de que sí debería existir, si estamos haciendo POO y en la vida misma todos tenemos 2 padres (papá + mamá para los menos entendidos) entonces porque los objetos en PHP no pueden heredar de 2 clases. La herencia de clases es muy diferente a implementar interfaces que estas si pueden ser múltiples pero carecen de muchas cosas útiles como declaración de variables o declaración de funciones, por ejemplo una interface es como un tío, o tu profesor sin embargo las clases de las que heredas son como tus padres o abuelos y cada uno de nosotros tenemos varios de esos. Aún no me entra en la cabeza porque en Java, el hijo pródigo de la POO no soporta este tema mientras C++, Eiffel y hasta .net en el framework 4.0 ya lo soportan. En PHP lo podría llegar a entender porque hasta PHP 5 casi ni conocía lo que era un obj

Errores comunes en PHP

Espero que este sea uno de una serie de artículos porque serán cosas que me voy encontrando y que son ‘errores’ comunes al programar en php. Resalto la palabra errores porque en realidad no lo son, son solo códigos muy frecuentes que me encuentro y que son fáciles de optimizar. en este primer artículo comenzaré por los más básicos. Funciones isset y empty Es muy común ver en una misma línea de código ambas comprobaciones, esto es un gasto de recurso porque la función empty si la variable no está definida retorna falso y no da error, por tanto si queremos utilizar ambas comprobaciones con solo utilizar empty es suficiente. La función isset sólo la debemos utilizar si la variable en cuestión puede tener valores vacios o si solo queremos saber si está definida o no. (comprobar que a==0 es más lento que empty(a) por la propia construcción de PHP). Recorrer un array Sobre las velocidades y pruebas tengo otros artículos de este mismo blog, en este punto solo quiero decir que nunca po