Acelera Visual Studio con Discos Solidos (SSD) y Tarjetas de Memoria

Después de leer varios artículos sobre los últimos modelos de discos SSD, y con el fin de acelerar mi trabajo con Visual Studio decidí adquirir un disco SSD modelo OCZ Core Series V2 SATA II 2.5″ SSD con 120 Gb,  las comparativas con los últimos modelos presentados por Intel X25, decían que incluso iban por delante en cuanto a rendimiento, su coste bastante inferior, de unos 340 € frente a los 650 € de un Intel.

 

Core_v2_back_b

La primera impresión cuando lo tienes en las manos es lo poco que pesa, parece un trozo de plástico. Después de clonar el equipo e instalar el disco duro, el rendimiento no parece mejorar, es mas en algunas operaciones incluso parece más lento, consultando en los foros del fabricante, leo que hay que hacer varios ajustes relativos al cache, el servicio de indexado, desfragmentación y otros. Para los interesados dejo los ajustes aquí http://www.ocztechnologyforum.com/forum/showthread.php?t=47212, que supongo haya que realizar en todos los discos SSD. Me pregunto si algunos serán correctos, no lo tengo muy claro.

Lo curioso es que después de hacerlo las búsquedas de archivos son espectaculares, sin embargo el rendimiento general aparentemente sigue siendo muy bajo, los tiempos de compilación con Visual Studio son similares a la utilización de un disco SATA de 7200 rpm, incluso en algunos casos más altos, los test de disco me decían que el rendimiento en lecturas secuenciales era espectacular, en cambio en lecturas aleatorias dejaba mucho que desear, la gran ventaja de la utilización de este disco es que la batería del portátil a pasado a durar más del doble, de dos horas a casi 5, sigo haciendo cambios en la configuración a través de regedit, pues el fabricante ni siquiera ofrece un programa de configuración, el disco tiene una conexión USB para actualizar el firmware, pero este brilla por su ausencia, lo curioso es que antes de comprarlo estuve leyendo en varios post, que los resultados obtenidos con este tipo de discos pasaban por un aumento de rendimiento en torno a un 30 % frente a un disco SATA Normal, en resumen toda una decepción, espero que con alguna actualización y soporte de Windows 7 para discos SSD el rendimiento pueda mejorar, pero no lo tengo nada claro.

Quizás, para trabajar con herramientas de diseño grafico como autocad que maneja archivos grandes el rendimiento mejore, pero en mi caso con Visual Studio me temo que con la cantidad de archivos que tiene la solución y el tamaño de estos que normalmente no supera 20 Kb no sea así. Lo cierto es que estoy bastante decepcionado con este disco, esperaba al menos cierta mejoria en el rendimiento tal y como se comentaba en los artículos.

Por otra parte acabo de renovar mi antiguo PC, un AMD con doble núcleo de los primeros que salieron al mercado, 4 Gb de Ram y un disco serial ata de 250 Gb, adquirí un equipo DELL Optiplex 960 con un procesador Intel Quad Core, 8 Gb de Ram, Vista 64 y un disco SSD de 64 Gb de la marca Samsung.

samsung_ssd_001

Como sabéis Visual Studio no permite realizar cambios en tiempo de ejecución cuando estas depurando en 64 bits, no entiendo porque ni despues del Sp1 han incoporado esta característica que es verdaderamente importante. Como trataba de potenciar el rendimiento decidi renunciar a esta opción.

Con esta configuración los resultados son espectaculares, se reduce el tiempo de compilación en un 70 %, el equipo abre outlook en decimas de segundo, realmente espectacular, el disco utilizado tiene la mitad de capacidad que el primero, pero en rendimiento nada que ver, impresionante, hay que tener en cuenta de que el procesador tambien hace su trabajo en el proceso de compilación los cuatro procesadores no bajan del 60 % de rendimiento, el sistema operativo es de 64 bits, el uso de memoria no sobrepasa los 4 gygas. Resharper y Devexpress van como un tiro. Es increíble que en un equipo que ronda los 1200 €, el rendimiento haya mejorado tanto, la verdad merece la pena la inversión.

Aprovechando este post, he realizado otra prueba utilizando una tarjeta de memoria de 4 Gb, similar a esta http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180 Desconozco la marca de la tarjeta que tengo ya que la consiguió un compañero a través de unos proveedores directamente en china, la de la foto es de la marca Gygabyte y es practicamente identica a la mia exceptuando la bateria que es una pila normal recargable de 1,5 V, En España todavía no he visto ningún sitio donde se comercializa.

desktop_productimage_i-ram_1.3_big 

Esta tarjeta te crea un disco virtual de memoria, esta sustentanda por una pequeña batería de litio que se recarga a través del slot PCI, para evitar perder los datos cuando apagamos el equipo, aquí también los resultados son espectaculares, después de dejar el proyecto en el disco de memoria que tiene una capacidad de 4 Gygas, suficiente para almacenar varios proyectos, y redirigir los archivos temporales a un directorio del propio disco, las pruebas son verdaderamente asombrosas, el rendimiento en la compilación es similar al logrado con el nuevo equipo con disco duro SSD. No os puedo poner el precio de esta tarjeta, pero según he leído es cara.

Otra posible solución de bajo coste para acelerar Visual Studio pasa por utilizar memorias Flash como las que se usan en las cámaras réflex digitales de alto rendimiento, abra que ver las especificaciones de lectura(escritura, esta es una de las mas rápidas actualmente..

g_00014498 

Se pueden utilizar como un disco mas en un portatil o se pueden conectar a traves de un interface SATA como el de la foto a cualquier PC, no he realizado las pruebas con este tipo de dispositivos, una memoria de 4 Gb similar a la de la foto no costara mas de 70 €, la de la foto de 8 Gb esta sobre los 110 € y el un interface para pc sobre los 20 €.

adsacf_detail

El ahorro de costes que puede suponer trabajar con este tipo de dispositivos puede ser espectacular, imaginar un equipo de 8 personas que compilen una media de 10 veces al día y el proceso tome unos 4 minutos, supone que podemos ahorrarnos 4 horas diarias solo en la compilación, aunque el dispositivo solo mejorase un 30 % el rendimiento, ya merece la pena realizar la inversión.

Otra solución muy interesante y gratuita para los que dispongais de suficiente memoria, al menos 3 Gygas, puede ser la utilización de este programa gratuito, https://www.cenatek.com llamado RamDiskVe, el programa crea un disco virtual utilizando la memoria ram del equipo, las pruebas que he realizado han logrado mejorar el proceso mas de un 30 %, aunque el rendimiento al guardar el contenido del todo el disco antes de apagar el equipo no es muy bueno y tiene algun problema, de hecho la versión para Windows Vista es beta, pero puede ser una buena alternativa que no nos cuesta nada probar.

En resumen, cuidado al comprar un disco SSD, no todos son iguales… los discos de memoria pueden ser una buena alternativa y si teneís memoria suficiente probar RamDiskVe.

Os dejo un video sobre el samsung SSD, tarda un poco, pero merece la pena. http://www.youtube.com/watch?v=pJMGAdpCLVg

[View:http://www.youtube.com/watch?v=pJMGAdpCLVg:540:0]

Espero que el post os resulte útil.

Diseñando controles. Atributo DesignerSerializationVisibility.

En el siguiente ejemplo hemos encapsulado un texbox dentro de un UserControl y añadido la propiedad MaxLenght para poder modificar la propiedad de control encapsulado.

Public class UserControl1 : UserControl
{
     public UserControl1()
     {
         InitializeComponent();
     }
 
     public int MaxLenght
     {
         get { return textBox1.MaxLength; }
         set
         {
             textBox1.MaxLength = value;
         }
     }
    
     private void InitializeComponent();
     {
         this.textBox1 = new System.Windows.Forms.TextBox();
         this.SuspendLayout();
         // 
         // textBox1
         // 
         this.textBox1.Location = new System.Drawing.Point(3, 3);
         this.textBox1.Name = "textBox1";
         this.textBox1.Size = new System.Drawing.Size(100, 20);
         this.textBox1.TabIndex = 0;
         // 
         // UserControl1
         // 
         this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
         this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
         this.Controls.Add(this.textBox1);
         this.Name = "UserControl1";
         this.Size = new System.Drawing.Size(108, 27);
         this.ResumeLayout(false);
         this.PerformLayout();
 
     }
 
     private System.Windows.Forms.TextBox textBox1;
}

Si arrastramos el control al formulario, observamos que en el código del InitialiceComponent del form aparece la siguiente linea:

this.userControl11.MaxLenght = 32767;

El generador de código ha añadido la propiedad con el valor por defecto en el InitializeComponent del formulario.

A partir de aqui solo se podra alterar el valor de la propiedad dentro del propio formulario, alterando manualmente su valor, esto obligaría a recorrer todos los formularios donde se usa el control.

El verdadero problema es que hagamos lo que hagamos en nuestro control el valor de la linea del InitializeComponent no cambiará ya que esta se introduce solo la primera vez que arrastramos el control al formulario. Con lo que el valor del Maxlengt en el formulario siempre sera 32767.

Si lo que buscamos es poder establecer a todos los controles una propiedad publica y un valor inicial, deberemos decirle a la propiedad que no se agrege a los contenedores donde se utilize el control. Esto se consigue decorando la propiedad con el atributo DesignerSerializationVisibility.

[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public int MaxLenght
{
    get { return textBox1.MaxLength; }
    set
    {
        textBox1.MaxLength = value;
    }
}

 

El atributo utilizado tiene tres valores posibles:

– Hidden. El generador de código no produce código para el objeto

– Visible. El generador de código produce código para el objeto

– Content. El generador de código produce código para el contenido del objeto más que para el objeto en sí.

De esta forma la linea del InitializeComponent no se introducira en el formulario, si alteramos el valor de la propiedad en el control, su valor se utilizará en todos los contenedores donde le utilicemos excepto en aquellos en que explicitamente cambiemos su valor.

Si establecemos la propiedad sin atributos debemos tener en cuenta que por cada propiedad se añadira al menos una linea en todos los sitios donde utilizemos el control, esto además de penalizar el rendimiento, porque el valor ha de ser cargado cada vez que abrimos el formulario, elimina la posibilidad de realizar cambios en el control y propagarlos a todos los sitios donde se utilize.

En el caso de una propiedad formada por un array inicializado con valores, el problema es mucho mayor, ya que podemos encontrarnos en nuestro formularios casos como este:

private void InitializeComponent();
{
 
       this.userControl13.Array = new string[] {
        "0",
        "1",
        "2",
        "3",
        "4",
        "5",
        "6",
        "7",
        "8",
        "9",
        "10",
        "11",
        "12",
        "13",
        "14",
        "15",
        "16",
        "17",
        "18",
        "19",
        "20",
        "21",
        "22",
        "23",
        "24",
        "25",
        "26",
        "27",
        "28",
        "29",
        "30",
        "31",
        "32",
        "33",
        "34",
        "35",
        "36",
        "37",
        "38",
        "39",
        "40",
        "41",
        "42",
        "43",
        "44",
        "45",
        "46",
        "47",
        "48",
        "49",
        
};
 
this.userControl13.Location = new System.Drawing.Point(30, 80);
this.userControl13.Name = "userControl13";
this.userControl13.Size = new System.Drawing.Size(108, 27);
this.userControl13.TabIndex = 2;

Es muy importante entender como funciona el generador de código de visual studio para decorar las propiedades de controles y formularios que vayan a ser reutilizados de forma adecuada evitando sobrecargar sus contenedores y aprovechar las ventajas de la herencia.

Cuestión de rendimiento…

Recientemente he leído varios artículos sobre las ventajas de Windows 7, frente a los actuales XP y Windows Vista. Los problemas de rendimiento de Windows Vista en algunos aspectos como la copia de archivos y otros han hecho que los usuarios ni siquiera se planteen el cambio de sistema operativo, personalmente opino que Vista es bastante superior que XP, aun con estos problemas que después se solucionaron con el sp1. Pero esta situación ha llevado a que Microsoft haya tenido que dar marcha atrás en su política, y se ponga manos a la obra para mejorar su Sistema Operativo optimizándolo para mejorar su rendimiento y cambiar la imagen de su producto más importante.

En el caso de Office 2007, el cambio radical con la adopción del Ribbon ha provocado que muchos usuarios rehúsen a usar este producto debido a su coste, la curva de aprendizaje que requiere el cambio de aspecto, además de que las necesidades de la mayoría de los usuarios se encuentran cubiertas en las anteriores versiones, han provocado que el número de implantaciones de Office 2007 se encuentren lejos de sus versiones anteriores.

Creo que la velocidad a la que nos viene acostumbrando Microsoft muchas veces solo justificada por la idea de vender nuevos productos al mercado, está comenzando a cambiar la forma de pensar de muchos usuarios, se ha creado un clima, en el que muchos piensan “porque cambiar algo que ahora mismo funciona y que cumple con mis necesidades” y que además cuesta dinero.

En mi caso, como desarrollador llevo “trabajando sufriendo” con Visual Studio desde hace varios años, “digo sufriendo porque gran parte mi tiempo estoy esperando…”, en mi opinión el diseño, su arquitectura y su integración con diferentes sistemas es excelente, pero arrastra desde las primeras versiones una serie de problemas que todos los días me hacen pensar si estoy utilizando la herramienta más adecuada, estoy harto de los tiempos de compilación, harto de los diseñadores de formularios lentos, por no hablar del diseño en Asp.net y Wpf  y de otros muchos aspectos relacionados con las pruebas unitarias y herramientas de calidad como FxCop que hacen que día a día pierda gran cantidad de tiempo, en esperar a que un proceso finalice. Si comparo mi actual proyecto con el anterior desarrollado en otro entorno también de Microsoft similar en cuanto a complejidad y funcionalidad, exceptuando por la calidad de código, entonces me dan ganas de llorar, un formulario normal con los mismos campos tarda en abrir decimas de segundo, la compilación con el doble de código y formularios se realiza en menos de 15 segundos, en cambio en Visual Studio puedo pasar hasta 10 minutos para que finalice el proceso, muchos pensaran quizás no deberías compilar tanto o ¿ Por qué no reduces el proyecto para que vaya más deprisa ?, optimizas tus clases, controles, etc. Creerme he hecho de todo desde optimizar, gestionar las builds, hasta utilizar discos SSD, pero hay veces que es necesario compilar a menudo y puedo afirmar que las diferencias de tiempo son abismales, sobre todo en lo que al diseño se refiere. El entorno de producción es increíblemente lento, la carga de los controles en el toolbar es desastrosa, en fin, hoy estaba estimando el tiempo que perdemos en estas tareas y la verdad, mejor no contarlo.

Espero que Microsoft tome nota de estas quejas que afectan todos los días a muchos programadores y que se comprometa tal y como predica, a realizar productos de calidad, en los que el rendimiento sobre todo en herramientas de desarrollo sea un aspecto fundamental, antes de sacar productos nuevos al mercado, estoy harto de los continuos cambios y nuevas tecnologías en las que solo funciona el 70 % de las cosas y que obligan a los desarrolladores a hacer verdaderas virguerías para poder desarrollar sus aplicaciones, estoy harto de escuchar frases como “eso se implementara en la siguiente versión”, y ver pasar errores que nunca se corrigen y que consumen mucho de nuestro tiempo productivo.

No quiero generalizar, considero que Microsoft tiene una amplia gama de productos excelentes, desde Sql Server pasando por Office e incluyendo como no a Visual Studio con el que mantengo desde hace tiempo una relación amor-odio, pero hay aspectos con los que lucho todos los días, y que versión tras versión siguen arrastrando los mismos errores, me pregunto cómo es posible que hace 10 años mi entorno de desarrollo fuese infinitamente más rápido para realizar la misma funcionalidad y hoy en día para realizar tareas cotidianas me encuentre con un entorno tan lento. Pienso que tal y como parece que están haciendo con Windows 7, deben replantearse su política y apostar por mejorar el rendimiento de sus productos, creo que hay muchos usuarios hartos ya de tantas versiones e innovaciones y que esperan realizar su trabajo de una forma más efectiva.

Creo en la innovación, pero no en la innovación a costa de no corregir y mejorar aquello que tienes por detrás. Como dicen en el desarrollo, los errores y la optimización de los módulos que lo requieran deben ser aspectos prioritarios.Creo que Microsoft con algunos productos ha empezado a pagar ya, su decisión de sacar productos cada poco tiempo e innovar a toda costa, y que en los sucesivos años todavía lo hará más si no cambia de política radicalmente.

Pero esta es solo mi opinión, estoy seguro que muchos no estaréis de acuerdo con estas afirmaciones.