Si ton code en C peut par la suite compléter les données acquises via le hachoir, cela signifie que le parser de données C est aussi complet que celui en python. Dans ce cas là, même pour l'indexation initiale il faudrait utiliser celui en C.
Mais moi j'aurais dit le contraire que toi à la limite: un parseur C initial ne sachant pas trouver toutes les meta-datas mais faisant un pool en gros et assez rapidement, puis utilisation d'un parser plus complet et dans un language plus lent pour l'incrémental.
Après tout, si la tâche est avec une priorité basse il n'y a pas de raison qu'elle gêne vraiment. Toutefois sous linux, les accès disques ont tendances à tirer le système en bas (faire tout ramer). Par exemple la je grave un DVD et le texte que je tape apparait avec plusieurs secondes de retard et pourtant j'ai un dual-core. Bon j'ai aussi du SATA et je crois que mon chipset est pas des mieux supporté, mais c'est un problème que j'ai déjà eu et j'ai l'impression que linux souffre plus des accès disque que windows (quelqu'un sait pourquoi ?)
[^] # Re: j'y connais rien de chez rien mais...
Posté par RB . En réponse au journal meta-tracker, le tueur de beagle .... Évalué à 3.
Mais moi j'aurais dit le contraire que toi à la limite: un parseur C initial ne sachant pas trouver toutes les meta-datas mais faisant un pool en gros et assez rapidement, puis utilisation d'un parser plus complet et dans un language plus lent pour l'incrémental.
Après tout, si la tâche est avec une priorité basse il n'y a pas de raison qu'elle gêne vraiment. Toutefois sous linux, les accès disques ont tendances à tirer le système en bas (faire tout ramer). Par exemple la je grave un DVD et le texte que je tape apparait avec plusieurs secondes de retard et pourtant j'ai un dual-core. Bon j'ai aussi du SATA et je crois que mon chipset est pas des mieux supporté, mais c'est un problème que j'ai déjà eu et j'ai l'impression que linux souffre plus des accès disque que windows (quelqu'un sait pourquoi ?)