Je crains qu'il n'y pas grand chose à changer dans ta fonction de parsing. Utiliser les regex pour parser consommerait trop de ressources. Et sur 50.000 lignes...

Pistes:
Tester le privilège FILE, si oui -> LOAD DATA INFILE
Sinon, envisager de faire tourner l'injection en arrière plan (voir mon lien plus haut).

Dernière suggestion, pour un script qui prend autant de temps, envisager d'empêcher l'utilisateur d'arrêter le script en plein milieu sous peine d'avoir une table incomplète. Pour ça, vois du côté de http://www.php.net/manual/fr/function.i ... -abort.php

OK, j'ai posé la question à mon hébergeur au sujet de la commande, on verra ce qu'ils vont répondre, s'ils répondent !

Je me suis aperçu que j'ai mis une requête SQL dans ma boucle (je me suis mélangé les crayons avec tous ces {} , alors que je n'avais besoin que d'un seule requête !!
Ca a nettement réduit le temps d'exécution du script, car je faisais cette requête sur une autre table !

Je vais tenter le coup de DROP index pour réduire encore, mais là j'y crois pas de trop.. et en plus ce sera pas mesurable avec mes temps de connexion pourris.

Merci encore pour tes conseils,

Restera après toutes ces optimisations à trouver une astuce indiquant au client que quelque chose se passe côté serveur et ne pas tomber dans le time out !!

@ ++,

Je vais tenter le coup de DROP index pour réduire encore, mais là j'y crois pas de trop..

Tu as tort car si tu fais un INSERT sur une table indexée, MySQL doit mettre la table ET l'index à jour. Et la mise à jour d'un index sur des grosses tables prend beaucoup de temps. Autant ne le faire qu'une seule fois, à la fin de l'injection.

et en plus ce sera pas mesurable avec mes temps de connexion pourris.

Je crois que la connnexion ne changera pas grand chose au temps d'exécution d'un script côté serveur

Restera après toutes ces optimisations à trouver une astuce indiquant au client que quelque chose se passe côté serveur et ne pas tomber dans le time out !!@ ++,

Tu fais tourner le script en arrière-plan en envoyant un header 200 OK (avec un texte du genre: "traitement en cours" et en continuant dans le même script l'injection. Pour le timeout, il n'y a rien à faire sinon négocier avec ton hébergeur!

edit

J'oubliais le sujet principal du post: la barre de de progression. Il manque un flush() dans ta fonction. Essaye:

    if ($NbQso % 500 == 0){
      $bar ='|';
      ob_start();
      $bar = strlen($bar) > 10 ? $bar : str_pad($bar, 10);
      echo $bar;
      ob_end_flush();
      flush();
    }

Testé dans FF et IE.

O,

Nos posts se sont croisés....

J'ai fait quelques tests avec DROP et sans, je ne vois pas de différence. En principe lorsque j'applique mon script, la base est vide donc de toute façon, ça ne devrait rien changer.
J'ai cependant fait des essais avec une base remplie de 55000 lignes, mais pareil, pas de différence significative.

Pour la barre, pas de différence en rajoutant le flush(), j'avais déjà tout essayé. Rien ne s'affiche pendant l'exécution, mais tout à la fin !
J'ai pourtant des données qui arrivent , puisque mon routeur indique de l'activité. Ca clignote à chaque paquet reçu, donc chaque |||

J'ai supprimé l'envoi de ||| pendant l'exécution du script, et là c'est pire, le script ne s'exécute pas et la base n'est pas remplie !
time out ...

Peut-être que du javascript pourrait résoudre le problème côté client, avec interruption quand arrive les données en fin du script ?

OK pour la tache de fond, je vais essayer. Jamais essayé..

Bon, je vais aussi préparer le réveillon...

@ ++,