j'ai toujours eu des soucis pour ouvrir des fichiers csv (ou texte, c'est kla même chose pour le coup) de plus de 1 GiO.
Peut-être une question d'outil? Ton outil, il ouvre le fichier et lit caractère par caractère, avec un fread (ou du même genre) à chaque fois? Ou il utilise mmap, ce qui permets de jouer avec les données comme si elles étaient en mémoire et donc réduit le nombre de syscalls nécessaire pour accéder à une donnée, en laissant le noyal fair boulot de gestion des accès aux ressources?
S'il utilise mmap, dans ce cas c'est probablement la même merde pout n'importe quel format texte: il faut toujours parser, on peut pas pas paralléliser pépère. Sauf si le format indique la taille en octets ou en caractères des champs, à la rigueur, mais ni xml ni json ne font ça. C'est plutôt les formats binaires qui font ça, mais je crois que c'est passé de mode... (enfin perso, si je dois bricoler un truc réseau, je préfère utiliser un format binaire, je trouve ça bien plus simple a implémenter)
[^] # Re: Il est où le problème dans le CSV ?
Posté par freem . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 5.
Peut-être une question d'outil? Ton outil, il ouvre le fichier et lit caractère par caractère, avec un
fread(ou du même genre) à chaque fois? Ou il utilisemmap, ce qui permets de jouer avec les données comme si elles étaient en mémoire et donc réduit le nombre de syscalls nécessaire pour accéder à une donnée, en laissant le noyal fair boulot de gestion des accès aux ressources?S'il utilise mmap, dans ce cas c'est probablement la même merde pout n'importe quel format texte: il faut toujours parser, on peut pas pas paralléliser pépère. Sauf si le format indique la taille en octets ou en caractères des champs, à la rigueur, mais ni xml ni json ne font ça. C'est plutôt les formats binaires qui font ça, mais je crois que c'est passé de mode... (enfin perso, si je dois bricoler un truc réseau, je préfère utiliser un format binaire, je trouve ça bien plus simple a implémenter)