ReloadData.. avec des rames
chaps31
Membre
Juste un truc perturbant, j'ai une tableview avec un tableau datasource qui se construit à partir d'une base postgresql.
Actuellement il y a une 20aine d'enregistrements uniquement pour tester pdt que je code, lorsque je crée un nouvel enregistrement (j'ai fais une interface pour ça dans mon appli) il va s'enregistrer dans la base de donnée et le tableau est mis à jour ainsi que la tableview avec un reloaddata. Le seul truc c'est que c'est lent...
Le temps de reload est d'environ 3 secondes, une éternité devant l'interface je vous assure, vous avez une idée de l'origine ?
Postgresql qui ne vaut pas mysql ? >:(
Le mode debug ? :why?:
Mon codage pas très propre... :P
Actuellement il y a une 20aine d'enregistrements uniquement pour tester pdt que je code, lorsque je crée un nouvel enregistrement (j'ai fais une interface pour ça dans mon appli) il va s'enregistrer dans la base de donnée et le tableau est mis à jour ainsi que la tableview avec un reloaddata. Le seul truc c'est que c'est lent...
Le temps de reload est d'environ 3 secondes, une éternité devant l'interface je vous assure, vous avez une idée de l'origine ?
Postgresql qui ne vaut pas mysql ? >:(
Le mode debug ? :why?:
Mon codage pas très propre... :P
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Heu... c'est à dire ? ??? Merci
Ah ben si tu connais pas le multi-threading, c'est sûr tu vas bloquer l'interface à mort avec ce genre de choses ???
http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/Introduction/chapter_1_section_1.html
EDIT : genre un thread qui met ma base de données à jour pendant qu'un autre thread met à jour mon tableau (1 ligne) et actualise l'affichage, du coup l'interface bosse rapidement même si en même temps la mise à jour de la base de donnée est plus lente.
C'est sûr pour coder moins je reprenais les méthodes déjà codées : un nouvel enregistrement allait se mettre dans la base puis l'interface rechargeait la base entière, pas vraiment un modèle de rapidité....
Tout cela vient du fait que je suis amateur et que je m'étais arrêté à la programmation en PHP non orienté objet... Je découvre tout un nouveau monde et pour ainsi dire, je découvre la programmation
Ce qui veut dire que pendant que ta base postgre se met à jour, ton interface n'est pas bloquée et t'auras pas de roue multicolore. C'est seulement quand la base postgre aura fini son boulot qu'elle va demander à l'interface de se mettre à jour, et ça c'est bien plus rapide que tes transactions postgre
Parce que sinon, sqlite est bien plus indiqué pour ce genre de choses
Si oui, en quoi sqlite est mieux que postgre ?
Changer de base de donnée ne pose pas de problème, quelques lignes de code à changer c'est tout.
C'est pour ça que je demandais si les données étaient sur un serveur distant...
Mais un doute m'assaille ; qu'appelles-tu multi-poste et mono-poste ??
C'est pas une question de mieux ou pas mieux ; c'est une question de base distante ou embedded locale...
SQLite, il n'y a pas de client/serveur.
Et donc en effet il y a deux choses à considérer dans le choix du SGBD : le nombre de connexions simultanées possibles, et l'aspect local ou distant.
Et il me semble si ma mémoire est bonne que sqllite est non seulement local, mais aussi mono-utilisateur (mono-client/mono-connexion)...
Toujours bon , Point de salut avec SQLite ?
NB : Pour le multiThread ça m'a pas l'air bien compliqué d'après ce que j'ai pu lire, sinon j'ai résolu mon problème en faisant l'effort de coder. En effet il y a 1 valeur de chaque enregistrement qui n'est pas fourni par l'utilisateur mais pas la base : un ID (auto_increment ou bigserial pour postgresql), donc de toute manière pas possible de faire du multithread sur ce coup car il faut que j'attende que l'enregistrement soit fait pour récupérer cet id (utile dans l'interface), mais j'ai recodé, et maintenant je n'extraits plus que l'id nécessaire de la base et j'update le tableau source de la tableview plustôt que de me servir du code déjà fait qui rapatrie toute la base et recré intégralement le tableau source.
Maintenant je bute sur un truc stupide : trier mon tableau source après avoir rajouté le nouvel enregistrement :
[tt]NSdescriptor *descriptor=[[[NSSortdescriptor alloc] initWithKey:@nom ascending:YES ] autorelease ];
NSArray *trie=[[NSArray alloc] initWithObjects:descriptor];
[matable sortedArrayUsingDescriptors:trie];[/tt]
Ca me fait un magnifique Bug :
[glow=red,2,300]0 CFRetain
1 CFArrayCreate[/glow]
...
Une idée ?
Suffit d'instaurer un système de lock :P
Je l'utilise avec un truc qui a plus de 10 threads, alors...
Si on peut toujours utiliser SQLite (via un WebService / SOAP), mais du coup, ça serait beaucoup plus complexe qu'un SGDB utilisant directement un système client / serveur -> postgre est le bon choix.
Non, le multi-thread c'est pas compliqué du tout... Par contre, quand tu dis que tu ne peux pas l'utiliser, j'ai un gros doute. Tu fais une connexion à une BDD, donc forcément pendant cette connexion, tu bloques l'interface, ce qui est contre les règles de programmation.
Quant à insérer un élément dans un tableau déjà trié, c'est un algorithme en O(log(n)) par dichotomie ; pourquoi vouloir retrier tout le tableau ?? ???
Un tri, aussi rapide soit-il est en O(n*log(n)), tu perds un facteur n, c'est énorme !
Je confirme, mais maintenant ça va vite (cf. ci-dessous), l'id fourni par la base de donnée est le champs qui différencie mes enregistrements dans ma programmation j'en ai besoin dans l'interface. C'est vrai que je peux updater mon tableau source sauf pour l'id qui vient après quand la base a fait son boulot mais entre temps si l'utilisateur utilise la fiche... Ca risque d'entrainer un bug...
"c'est un algorithme en O(log(n)) par dichotomie " hum... si tu le dis :P En tout cas c'est sûr c'est stupide je suis d'accord, pour tout te dire au lancement de l'appli la base est rapatriée intégralement triée (ORDER BY) dans le tableau source, j'ai une méthode qui le fait, donc par petite flemme, lors d'un nouvel enregistrement hop j'appelle la méthode toute faite... Maintenant que j'ai recodé et ne traite que le nouvel enregistrement c'est instantané mais sans trie, que je n'arrive pas à faire fonctionner.
Si j'ai bien compris tu me déconseilles de retrier le tableau, donc il faut que je place le nouvel enregistrement au bon endroit dans le tableau... il faut que j'énumère les lignes jusqu'à trouver la bonne place alphabétique... C'est plus rapide que les sortdescriptor que je n'arrive pas à utiliser ?
Ce qu'on fait dans pareil cas, c'est qu'on met à jour les données en mémoire avec la base dans un thread ; une fois terminé, le thread appelle :
Non, il faut faire une insertion dichotomique...
http://fr.wikipedia.org/wiki/Dichotomie
On ne peut pas programmer sans connaà®tre les concepts principaux d'algorithmique ???
Le principe, c'est que pour insérer à la bonne place un élément dans un tableau ordonné de 1M d'entrées, il faut juste 20 tests.
Alors que l'insérer à la fin et re-trier, ça sera de l'ordre de 20M d'opérations.
EDIT : Je viens de programmer ma première recherche par dichotomie, je dois avouer que c'est impressionant d'efficacité, bon j'ai juste une erreur de 1 ou 2 places faut que je creuse
Bien sûr que c'est efficace ; c'est de l'ordre du log (on divise par 2 à chaque test)... :P
À chaque fois qu'on double la taille de la liste, on n'ajoute qu'un test !
Pourquoi crois-tu qu'un être humain normalement constitué retrouve aussi rapidement une définition dans un dictionnaire de 42.000 mots?
Grâce à la dichotomie
Ouais, mais une dichotomie à la fois plus optimisée (parce qu'on a en plus un concept de " guess " ; genre ah, " cacao " ça devrait être à peu près vers le début) et moins optimisée (souvent, au lieu de faire un test à la moitié de la partie courante de recherche, on fait 1 test sur chaque dixième à peu près).
Cours complet, je connais pas ; mais en général, il suffit de connaà®tre les termes et de faire des recherches...
quelques concepts très importants : le backtracking, la récursivité, la dichotomie, les heuristiques...
Plus évolué : min-max / alpha-bêta, tris rapides (quicksort), théorie des graphes...
Plus spécialisés : réseaux de neurones, algorithmes génétiques, logique floue...
Cela manque.
M'étonnerait fort ; les listes chaà®nées ne sont pas faites pour un accès rapide à un élément particulier...
À mon avis c'est une implémentation bien plus complexe que ça.
Il reste néammoins que l'implémentation d'une classe NSMutableSortedArray n'est pas une montagne, et que cela manque.
Pour une insertion dans un tableau trié de 1 Mo --> 9 dixième de seconde
% clear;gcc pgm.m -o pgm -framework Cocoa
% pgm
AAAA
AAAB
AAAC
AAAD
AAAE
2008-04-11 14:03:14.737 pgm[1366:10b] 0.85
AAAA
AAAB
AAAC
AAAC&
AAAD
%
1 Mo ça fait au maximum 1M d'éléments, soit 20 tests ???
On essaye
Il a fait un peu l'analyse de tout ça déjà , avec entre autres un graphique surprennant de par le résultat qu'il illustre sur CFArray/NSArray :
Comparativement aux autres graphes qu'il fait sur les tableaux naà¯fs, les listes chaà®nées, les tables de hachage & co... très intéressante lecture.
Erreur
Ben écoute, je sais pas trop comment t'as fait tes tests alors :P
(tu m'excuseras, j'ai re-pompé ton code en grande partie...)