Tengo curiosidad por si alguien ha realizado alguna prueba de rendimiento al consultar ContentProvider
a través de frente a consultar un objeto SQLiteDatabase
en el mismo proceso. Supongo que una consulta ContentResolver
devuelve un Cursor que se comunica con la base de datos a través de un Binder (Android IPC). Esto significa que si leo el contenido de 100 registros a través del Cursor
, se obtendrán 100 llamadas al método Binder. ¿Son correctas mis conjeturas y, de ser así, sería mucho más lento que acceder a la base de datos en el mismo proceso?Android ContentProvider Performance
Respuesta
No he hecho exactamente esa medida. Lo que hice fue medir el rendimiento de múltiples inserciones a través de un ContentProvider o directamente a través de una base de datos SQLite. Inserté alrededor de 1000 artículos (uno por uno). Fue mucho más lento insertarlo a través de ContentProvider. En mi prueba casi un 10% más lento.
Si va a insertar 1000 elementos uno por uno, usará 'ContentProviderOperation' y realizará una' batchInsert'. Insertar 1000 elementos, uno por uno, será increíblemente lento sin importar el uso que usted haga, por lo que no consideraría demasiado este punto de referencia. En mi experiencia, la diferencia entre "usar un' ContentProvider' "y" no usar un 'ContentProvider'" nunca se ha reducido a la velocidad/eficiencia con la que se llevan a cabo las operaciones. –
- 1. ContentProvider Android no volver Phone.NUMBER
- 2. Android SQLite Performance con índices
- 3. Sencha Touch 2 - Android Performance
- 4. Sencha Touch 2 android performance
- 5. Serialization Performance y Google Android
- 6. Android: llamar a métodos personalizados en ContentProvider
- 7. Diferencias entre Android IPC y ContentProvider
- 8. Android ContentProvider database query multiple tables
- 9. Android ContentProvider y Google IO Resto Talk
- 10. Probar un ContentProvider personalizado en Android
- 11. Android - Uso del patrón Dao con contentProvider
- 12. CALayer performance vs. UIImageView performance
- 13. Android Contentprovider - actualización dentro de un método de inserción
- 14. Android CursorLoader no responde a las notificaciones de ContentProvider
- 15. @string para android: las autoridades en un ContentProvider
- 16. Android ContentProvider getType() llamado cuándo y por qué
- 17. Android: ContentProvider para cada tabla/manipulación relaciones uno-a-muchos
- 18. Flujo de datos entre Android BroadcastReceiver, ContentProvider y Activity?
- 19. SyncAdapter sin ContentProvider
- 20. ContentProvider sin SQL
- 21. Custom ContentProvider - openInputStream(), openOutputStream()
- 22. ClassNotFoundException para un ContentProvider
- 23. Mejores prácticas para SQLite DB y ContentProvider
- 24. Cómo crear un ContentProvider Thread-safe?
- 25. string.IndexOf performance
- 26. Log4Net performance
- 27. JRuby Performance
- 28. MethodBase.GetCurrentMethod() Performance?
- 29. OracleBulkCopy Performance
- 30. glFramebufferTexture2D performance
Como nota al margen, realicé una prueba en un dispositivo Android de 800MHz al comparar una llamada a métodos locales contra llamadas a métodos remotos. Llamar a un método remoto con un simple parámetro de cadena de 26 caracteres lleva unos 400 nanosegundos más que llamar a un método local. El envío de un parámetro de cadena de 10.000 caracteres demora 2.3 milisegundos. Claramente, cuantos más datos se envíen (o reciban), más tiempo llevará. – satur9nine
Algo que aprendí: los cursores pasados por ContentProviders contienen un CursorWindow, CursorWindow es un área en caché del Cursor de 2MB de tamaño, la mayoría de las consultas caben en todo el buffer. Por lo tanto, el acceso a los datos del Cursor generalmente no inicia una llamada al método Binder ya que todos los datos ya están allí, sin embargo, si intenta leer datos fuera de CursorWindow en un gran cursor, la Ventana deberá moverse y la caché se reentrará el aglutinante. – satur9nine