2011-02-23 16 views
5

Tengo un archivo .JSON que es de aprox. 1.5 MB de tamaño que contiene alrededor de 1500 objetos JSON que quiero convertir en objetos de dominio al inicio de mi aplicación.Problema de rendimiento de serialización JSON en WP7

Actualmente mi proceso en el teléfono (no en mi PC de desarrollo) toma alrededor de 23 segundos, lo que es demasiado lento para mí y me obliga a escribir la lista de objetos en ApplicationSettings para no tener que hacerlo cada vez la aplicación se carga (solo primero), pero incluso eso lleva 15 segundos para escribir y 16 segundos para leer, todo lo cual no es realmente lo suficientemente bueno.

No he tenido mucha experiencia de serialización y realmente no conozco la forma más rápida de hacerlo.

Actualmente, estoy usando el espacio de nombre System.Runtime.Serialization con DataContract y DataMember enfoque.

¿Alguna idea sobre el rendimiento con este tipo de carga de datos?

+1

la primera pregunta sería ¿** necesita ** para convertir todos los 1500 objetos en el inicio? –

+0

sí :) hay una necesidad desafortunadamente – Mark

+0

http://servicestack.net/benchmarks/ –

Respuesta

4

Encontré que la biblioteca Json.NET era más eficaz y tenía mejores opciones que el serializador json estándar.

Un problema de rendimiento que encontré en mi aplicación fue que los objetos de mi dominio implementados INotifyPropertyChanged con código para admitir el envío del evento al hilo de la interfaz de usuario. Como el código de deserialización pobló esas propiedades, estaba haciendo una gran cantidad de discusiones de hilos que no necesitaban estar allí. Cortar las notificaciones durante la deserialización aumentó sustancialmente el rendimiento.

Actualización: Estaba usando Caliburn Micro que tiene una propiedad en PropertyChangedBase que puede desactivar las notificaciones de cambio de propiedad. Luego añade lo siguiente:

[OnDeserializing] 
public void OnDeserializing(StreamingContext context) 
{ 
    IsNotifying = false; 
} 

[OnDeserialized] 
public void OnDeserialized(StreamingContext context) 
{ 
    IsNotifying = true; 
} 
+0

parece que este está haciendo un buen trabajo hasta ahora :) – Mark

+0

@NigelSampson podría proporcionar un poco más de detalle sobre lo que cambió cuando cortó las notificaciones durante la deserialización? Creo que me estoy encontrando con esto actualmente ... – GotDibbs

+0

Actualizado con mi solución –

0

Almacenar/restaurar en ApplicationSettings va a implicar serialización también (bastante seguro de que es Xml) así que no creo que vaya a obtener más rápido que los 16 segundos que está viendo.

Mover esa cantidad de datos no va a ser rápido, no importa cuán bueno sea el deserializador. Mi recomendación sería ver por qué estás almacenando tantos objetos. Si no puede reducir el conjunto de objetos que necesita almacenar, desglosarlos en grupos lógicos para que pueda cargar a pedido en lugar de hacerlo por adelantado.

+0

sí, estoy de acuerdo, creo que JSON.NET se ve bien hasta ahora – Mark

1

Trate perfil de su aplicación con el libre EQATEC Profiler para WP7. El verdadero problema podría ser algo completamente inesperado y fácil de solucionar, como el INotifyPropertyChanged-example que menciona Nigel.

+0

Sugerencia impresionante, utilicé el generador de perfiles para encontrar ese problema. –

+0

¡Excelente! Como desarrollador principal en el generador de perfiles, estoy muy contento de que haya sido útil encontrar otro cuello de botella inesperado :-) –

0

¿Ha intentado utilizar varios archivos más pequeños y [de] serializar en paralelo para ver si eso será más rápido?

1

Puede dispararse rápidamente en el pie usando la configuración de la aplicación. El problema es que estos siempre se serializan/deserializan "a granel" y se cargan en la memoria, por lo tanto, a menos que los objetos sean extremadamente pequeños, esto puede ocasionar problemas de memoria y rendimiento en el futuro.

Todavía me pregunto acerca de la necesidad de 1500 objetos. ¿De verdad necesita 1500 de todo el objeto, y si es así, por qué? En última instancia, el teléfono muestra algo al usuario y ningún usuario puede procesar 1500 bits de información a la vez. Solo pueden procesar la información que se presenta, ¿no? Entonces, ¿hay partes posibles del objeto que pueda mostrar, y espere cargar las otras partes hasta más tarde? Por ejemplo, si tengo 2000 contactos, nunca cargaré 2000 contactos.Puedo cargar 2000 nombres, dejar que el usuario filtre/clasifique los nombres, y luego cuando seleccionan un nombre cargan el contacto.

Sugeriría serializar esto para el almacenamiento aislado como un archivo. El serializador JSON incorporado tiene la huella más pequeña en el disco y funciona bastante bien.

1

Here es una publicación sobre la serialización. Use binary o Json.Net.

Cuestiones relacionadas