1. J'ai gagné 20 à 30% en supprimant l'"ATTACH DATABASE" qui permet de lier les tables de 2 fichiers sqlite. (j'avais 1 fichier pour les données USER et 1 fichier pour les données en lecture seulement). C'est toujours ça.
2. Je n'ai rien gagné en supprimant l'encryption (SQLCypher), et c'est tant mieux je vais pouvoir la garder.
3. Ma prochaine piste est un travail sur les clés. J'ai du (VARCHAR) au lieu de (INT) actuellement car les les Ids sont des UDID pour la synchro (système multi-devices, multi-plateforme). Cependant, c'est un gros chantier et comme les clés primaires sont indexées par défaut, même en VARCHAR, je ne suis pas sûr que ça apporte quelque chose.
Enfin, pour ceux qui me demandaient le EXPLAIN QUERY PLAN (mais j'ai vraiment l'impression que les index sur les clés étrangères n'apportent rien)
Le "USE TEMP B-TREE FOR GROUP BY" est aussi présent dans la précédente version de la requête (sans les ajouts) ?
Oui, voir ci-dessous.
La seule chose qui a change c'est que j'ai un peu plus de jointures (certes ce n'est pas un détail, mais en les supprimant je n'ai pas obtenu la différence escomptée).
3. Ma prochaine piste est un travail sur les clés. J'ai du (VARCHAR) au lieu de (INT) actuellement car les les Ids sont des UDID pour la synchro (système multi-devices, multi-plateforme). Cependant, c'est un gros chantier et comme les clés primaires sont indexées par défaut, même en VARCHAR, je ne suis pas sûr que ça apporte quelque chose.
Juste pour donner une piste.
Sur un de nos site internet, on avait un forum qui devenait de plus en plus lent. (Plusieurs secondes pour afficher la premiere page d'un sujet). Le simple fait d'avoir passé toutes les colonnes de type varchar qui servaient aux jointures en des colonnes de type int, a diminué le temps d'exécution de plusieurs requêtes d'un facteur 10.
Tu peux dans tout les cas créer une colonne supplémentaire de type INT qui servira pour tes jointures. Et garder tes UDID pour le reste de ton appli. C'est un réflexe qu'on m'a appris, d'avoir toujours un champ de type int pour la clé primaire de la table, même si théoriquement l'id peut être mieux représenté par une chaine (email, udid, etc...).
J'ai pu gagné du temps également en balançant 1 de mes 2 requêtes en background.
EDIT: sinon, pour info MySQL s'accomode très bien des clés en VARCHAR (avec des index). J'ai des résultats immédiats avec des millions d'enregistrements et des jointures, sur un serveur partagé en plus. SQLite est bien plus "faible", mais je le savais (pas le même type de moteur).
EDIT: sinon, pour info MySQL s'accomode très bien des clés en VARCHAR (avec des index). J'ai des résultats immédiats avec des millions d'enregistrements et des jointures, sur un serveur partagé en plus. SQLite est bien plus "faible", mais je le savais (pas le même type de moteur).
Oui c'est ce que je pensais aussi, et pourtant sur notre site (en mysql), passer sur des colonnes numériques pour les id, a vraiment tout changé.
Si on avait mis des index sur les clé primaires, et sur les clés étrangères. C'était surtout pour une jointure sur deux grosses tables de plus de 10 000 000 l'une et 2 000 000 l'autre.
Réponses
ton dequeueReusableCellWithIdentifier me parait très lent. T'as quoi dans ta cellule ?
T'aurais pas plusieurs cellules dans le même xib ?
6 TextFields, 1 imageview, 2 ou 3 custom views.
Je n'ai qu'une cellule dans mon xib.
Bon sur la base:
1. J'ai gagné 20 à 30% en supprimant l'"ATTACH DATABASE" qui permet de lier les tables de 2 fichiers sqlite. (j'avais 1 fichier pour les données USER et 1 fichier pour les données en lecture seulement). C'est toujours ça.
2. Je n'ai rien gagné en supprimant l'encryption (SQLCypher), et c'est tant mieux je vais pouvoir la garder.
3. Ma prochaine piste est un travail sur les clés. J'ai du (VARCHAR) au lieu de (INT) actuellement car les les Ids sont des UDID pour la synchro (système multi-devices, multi-plateforme). Cependant, c'est un gros chantier et comme les clés primaires sont indexées par défaut, même en VARCHAR, je ne suis pas sûr que ça apporte quelque chose.
Enfin, pour ceux qui me demandaient le EXPLAIN QUERY PLAN (mais j'ai vraiment l'impression que les index sur les clés étrangères n'apportent rien)
Le "USE TEMP B-TREE FOR GROUP BY" est aussi présent dans la précédente version de la requête (sans les ajouts) ?
Tu as ajouté des clauses dans le GROUP BY ?
Je ne pensais pas que l'ATTACH avait autant d'impact. C'est bon à savoir.
Oui, voir ci-dessous.
La seule chose qui a change c'est que j'ai un peu plus de jointures (certes ce n'est pas un détail, mais en les supprimant je n'ai pas obtenu la différence escomptée).
Juste pour donner une piste.
Sur un de nos site internet, on avait un forum qui devenait de plus en plus lent. (Plusieurs secondes pour afficher la premiere page d'un sujet). Le simple fait d'avoir passé toutes les colonnes de type varchar qui servaient aux jointures en des colonnes de type int, a diminué le temps d'exécution de plusieurs requêtes d'un facteur 10.
Tu peux dans tout les cas créer une colonne supplémentaire de type INT qui servira pour tes jointures. Et garder tes UDID pour le reste de ton appli. C'est un réflexe qu'on m'a appris, d'avoir toujours un champ de type int pour la clé primaire de la table, même si théoriquement l'id peut être mieux représenté par une chaine (email, udid, etc...).
Oui, comme je disais c'est une piste, je vais essayer de la mettre en pratique, mais ça ne sera pas évident (à cause de la synchro).
J'ai aussi essayé cette piste-là :
http://www.sqlite.org/withoutrowid.html
qui n'a rien donné.
J'ai pu gagné du temps également en balançant 1 de mes 2 requêtes en background.
EDIT: sinon, pour info MySQL s'accomode très bien des clés en VARCHAR (avec des index). J'ai des résultats immédiats avec des millions d'enregistrements et des jointures, sur un serveur partagé en plus. SQLite est bien plus "faible", mais je le savais (pas le même type de moteur).
Oui c'est ce que je pensais aussi, et pourtant sur notre site (en mysql), passer sur des colonnes numériques pour les id, a vraiment tout changé.
Vous n'aviez p-e pas mis d'index sur vos clés étrangères qui servent sur les jointures ?
Si on avait mis des index sur les clé primaires, et sur les clés étrangères. C'était surtout pour une jointure sur deux grosses tables de plus de 10 000 000 l'une et 2 000 000 l'autre.