Project

General

Profile

Evolution #3071

Performance boucle DATA sur CSV

Added by lrt rln over 7 years ago. Updated 2 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
compilo
Target version:
Start date:
10/09/2013
Due date:
% Done:

0%

Resolution:

Description

Il semble que l'analyse CSV avant passage dans la boucle DATA pose de gros soucis de perf. Le temps d'exécution passe rapidement à 2/3 minutes (avec gros set_time_limit) de traitement sur des fichiers >10Mo. A titre comparatif un simple fgetcsv avec un while (($data = fgetcsv($handle, 1000, ",")) est 50 fois plus rapide en exécution que le traitement par la boucle DATA. Il y a sans doute moyen d'optimiser /inc/csv.php pour éviter un plantage assez systèmatique de PHP sur bouclage de fichiers de + 5000 lignes.

History

#1 Updated by lrt rln over 7 years ago

Un petit exemple avec un fichier récupéré un peu au hasard sur la plate-forme opendata de la ville de Paris :
le fichier //parisdata.opendatasoft.com/explore/dataset/arbresalignementparis2010/download?format=csv

<BOUCLE_csv(DATA){source csv, arbresalignementparis2010.csv}>
..
sur serveur local (4 coeurs / 8GoRAM) le temps d'exécution pour la lecture globale des 237.000 lignes du fichier est proprement monstrueux.

#2 Updated by Fil _ over 7 years ago

En effet il serait intéressant d'utiliser fgetcsv; c'est très facile d'ajouter un mode de lecture dans la boucle DATA. (J'avoue que je ne sais pas pourquoi on a développé un module de lecture des CSV spécifique, il faudrait enquêter sur l'historique, ou demander sur la liste spip-dev.)

#3 Updated by cam.lafit - over 7 years ago

Ciao

fgetcsv n'est pas fiable (ou du moins incomplet). Entre autre on peut rencontrer des problèmes avec les différents formats de saut de ligne comme \r\n et \n. De plus le support du caractère d'échappement est limité.
On peut voir certains commentaires sur http://www.php.net/manual/fr/function.fgetcsv.php#58124 pour mieux comprendre les contraintes associées à cette fonction.

Si on veut un truc robuste on ne peut se contenter des fonctions php. C'est je suppose la cause du fichier dédié dans SPIP.

#4 Updated by cedric - over 7 years ago

Une implémentation d'import CSV avec fgetcsv est disponible depuis assez longtemps dans le plugin Bonux
http://zone.spip.org/trac/spip-zone/browser/_plugins_/spip-bonux-3/inc/importer_csv.php

Je l'utilise très régulièrement pour des imports plus ou moins gros sans soucis.
Aucune idée pourquoi il a été choisi de re-développer un parsing CSV indépendant.

#5 Updated by esj - over 7 years ago

De l'utilité de faire "svn cp" et non une copie dans éditeur perso pour que l'historique d'un code soit facile à retrouver.

Ce code est apparu en 2007 dans r10948 qui répondait à une difficulté signalée dans Spip-contrib, à laquelle il fut répondu par un code, documenté sur spipnet comme il se doit:
http://contrib.spip.net/Creer-de-grands-tableaux-dans-SPIP,9#forum401060

Cette fonction faisait alors 3 lignes, c'était plus rapide à écrire que de regarder si PHP avait l'équivalent en magasin.
Ensuite, il y a eu quantités de signalements de problèmes, ce format propriétaire à l'origine ayant un RFC tardif et imprécis dont tout le monde se fout,
d'où un code qui n'a pas cessé de croître avec les années (r11111, r11113, r13859, r14013 surtout). Au vu du commentaire dans la doc PHP de fgetcsv, ce code semble toujours d'actualité. En tout cas il y a intérêt à vérifier que les cas signalés dans les logs des commit ci-dessous sont bien pris en compte par cette fonction avant de mettre le code des autres à la poubelle sans chercher à comprendre, marque de fabrique de SPIP3.

#6 Updated by cedric - over 6 years ago

  • Target version set to 3.2

#7 Updated by cedric - 2 months ago

  • Target version changed from 3.2 to 3.4

Also available in: Atom PDF