Carga Aplicación lenta en arranque frio

bxavi · #1 (**permalink**) 04/05/2017, 02:30

Buenos dias.

Queria exponer el problema que tengo, al ejecutar mi aplicación en un arranque en frio ( justo al reiniciar el pc) en ciertas maquinas se hace lentisimo para que aparezca la pantalla de la aplicación, como 12 segundos.

Demasiado verdad?

Luego la segunda vez que la arrancan ya funciona normal.

Mas datos:

- Aplicación WPF de esctritorio programada en c#

- Al ejecutar la aplicación la pantalla de splashcreen aparece instantaneamente, y la del login a los 2-3 segundos (esto es aceptable).

- Cuando se escribe el usuario y password y se acepta es ahi donde esta el cuello de botella y tarda como 12 segundos en aparecer el menu principal. (en arranque en frio luego las siguientes veces que se entra ya va normal)

- Asi que dudo en que puede ser, el codigo tampoco realiza nada excepcional:

1.- Podria ser algun problema en la conexión a la base de datos sql local?

2.- Podria ser de la estructura de la solucion? me explico, el programa es heredado de un compañero y esta compuesto de una solucion con 5 proyectos dentro

- Backend.UI (donde estan los formularios de visualizacion y funcionalidades)

- Business (donde pone los BLO)

- Data (donde pone los DAO)

- Domain (donde pone los entities)

- Resources (Ficheros de resources)

Es correcta esta estructuración? No seria mejor ponerlo todo en un solo proyecto separado cada cosa con su carpeta?

Lo digo por lo siguiente, analizando con el debug veo que hasta la primera pantalla de login solo carga

(CLR v4.0.30319: DefaultDomain): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.BackEnd. UI.exe'. Symbols loaded.

Y una vez aceptado el login hasta el menu principal carga los demas modulos.

(CLR v4.0.30319: xxxx.BackEnd.UI.exe): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.Domain.d ll'. Symbols loaded.

(CLR v4.0.30319: xxxx.BackEnd.UI.exe): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.Business .dll'. Symbols loaded.

(CLR v4.0.30319: xxxx.BackEnd.UI.exe): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.Data.dll '. Symbols loaded.

Puede ser este el problema? que al tener varios proyectos (que no creo que hagan falta tenerlos separados) tenga que cargarlos y eso ocupe tiempo....

De antemano agradecido por cualquier comentario.

Saludo.

Drako_18 · #2 (**permalink**) 04/05/2017, 09:39

Buenas compañero,

Es una aplicación de escritorio y dentro de una red local ¿no?
Intuyo... Que esos segundos son por temas de enrutación...
Podrías depurar el botón "login" para ver si realmente lo que tarda es la conexión con la base de datos... O si es otro tema...

Un saludo!

alan_69niupi · #3 (**permalink**) 04/05/2017, 09:43

La estructura en capas es correcta, no afecta porque si es un compilado que ejecutas es decir un .exe lo que lee son dll's. Ahora si estas iniciando la maquina e inmediatamente ejecutas el .exe recuerda que el SO tiene que cargar ciertas cosas que al inicio hace muy lentos todos los procesos. Probablemente tarde un poco en cargar el SQL y eso hace lenta tu aplicación, observa el comportamiento con el administrados de tareas.

Saludos!!!

agleiva · #4 (**permalink**) 04/05/2017, 15:33

Hay muchas posibles optimizaciones que podes ir probando.

Los guidelines de Microsoft para apps de Windows indican que cualquier operacion que tarde mas de 500 ms (milisegundos) debe ser ejecutada de manera asincronica para no "congelar" la pantalla:

https://blogs.msdn.microsoft.com/win...tro-style-app/

Lo primero que yo haria es verificar esto: todo acceso a la base de datos, servicios externos, u otras operacione de I/O las tendrias que hacer con async/await en C#.

Lo segundo que veria es si podes hacer algo para levantar tempranamente las DLLs que tenes que cargar, durante el splash, para aliviar la carga de la ventana principal. Esto lo podes hacer simplemente referenciando en el codigo alguna clase dentro de dichas DLLs. Este load time lo vas a tener de todas formas, pero lo podes mover al splash para una mejor experiencia de usuario.

bxavi · #5 (**permalink**) 05/05/2017, 07:49

Buenas gente.

Gracias por contestar.

La verdad que ya lo solucione.
Consegui un tiempo mas o menos aceptable, y siempre hablando del arranque en frio, la segunda vez y posteriores arranques va como un tiro...

La solución?
Hice varios cambios asi que no se bien bien de donde venia pero si se seguro que provenia de uno de estos dos cambios:
1.- Agrupe los 5 proyectos en uno solo (y dentro separado en sus respectivas carpetas).
2.- Elimine muchos using ... que no hacian falta en las pantallas principales, namespaces innecesarios pero que el ultimo desarrollador habia dejado.

Saludos.

agleiva · #6 (**permalink**) 05/05/2017, 08:15

Cita:

Iniciado por bxavi

Buenas gente.

Gracias por contestar.

La verdad que ya lo solucione.
Consegui un tiempo mas o menos aceptable, y siempre hablando del arranque en frio, la segunda vez y posteriores arranques va como un tiro...

La solución?
Hice varios cambios asi que no se bien bien de donde venia pero si se seguro que provenia de uno de estos dos cambios:
1.- Agrupe los 5 proyectos en uno solo (y dentro separado en sus respectivas carpetas).
2.- Elimine muchos using ... que no hacian falta en las pantallas principales, namespaces innecesarios pero que el ultimo desarrollador habia dejado.

Saludos.

Poner todo en un solo assembly no es la mejor idea ya que no te permite eventualmente reutilizar la funcionalidad. Esto a lo mejor no es un problema para ese proyecto en particular, pero no es aconsejable como una solucion general.

Los using no tienen nada que ver ya que es un constructo meramente de tiempo de compilacion y no existe en runtime. No hay forma de que eso afecte la performance.

bxavi · #7 (**permalink**) 05/05/2017, 09:08

Cita:

Iniciado por agleiva

Poner todo en un solo assembly no es la mejor idea ya que no te permite eventualmente reutilizar la funcionalidad. Esto a lo mejor no es un problema para ese proyecto en particular, pero no es aconsejable como una solucion general.

Los using no tienen nada que ver ya que es un constructo meramente de tiempo de compilacion y no existe en runtime. No hay forma de que eso afecte la performance.

Buenas Agleiva.

He estado informandome por curiosidad y tienes toda la razon, los using innecesarios no deberia afectar.

Lo que no tengo tan claro es lo de los proyectos, si esos proyectos tuvieran reference innecesarias si que podria afectar no?
Claro que cada proyecto solo deberia tener las references que afectasen o que necesitara, pero en este caso me huelo que lo que fue haciendo el desarollador fue "copiando" el proyecto y arrastrando las references, porque todos los proyectos los 5 tenian las mismas referencias, esto no deberia ser asi verdad?

Hablo desde la perspectiva de novato, hace poco tiempo que me adentre en el mundillo .net.

Gracias.
Saludos.

Drako_18 · #8 (**permalink**) 06/05/2017, 07:10

Buenas compañero,

Una pregunta... Estas publicando/generando la aplicación como Release y no debug ¿no?
Intuyo que lo estás probando como Debug... Y si es así, por eso puede ser que te tarde un poco más la primera vez...

Lo de tener varios proyectos no pasa nada, no relentiza... Ten en cuenta que eso son varias dll's y que se cargan en el inicio de la app (o deberían).

Un saludo!

bxavi · #9 (**permalink**) 08/05/2017, 10:35

Cita:

Iniciado por Drako_18

Buenas compañero,

Una pregunta... Estas publicando/generando la aplicación como Release y no debug ¿no?
Intuyo que lo estás probando como Debug... Y si es así, por eso puede ser que te tarde un poco más la primera vez...

Lo de tener varios proyectos no pasa nada, no relentiza... Ten en cuenta que eso son varias dll's y que se cargan en el inicio de la app (o deberían).

Un saludo!

Buenas Drako.

Ahi se nota mi estado de novato xD.
Si lo estoy generando en modo Debug, puede ser este un motivo tambien que el .exe que genere luego provoque esa tardanza la primera vez al arrancar el pc?
En que influye.

Bueno de todas formas voy a probar como Release y te comento.
Gracias.
Saludos.