La recherche des fichiers n’est pas si consommatrice. La structure des répertoires est très légères et, sauf le premier accès, va être pauvre en IO. Ce qui va se jouer c’est le syscall (permutation user-kernel mode), et les différents algo. en œuvre pour la résolution du chemin, la vérification des droits, etc. Par défaut, par exemple, la liste des fichiers est très souvent triée dans le monde Unix, au lieu d’être restituée dans l’ordre présent sur le disque (± l’ordre dans lequel ça a été écrit). Il y a de quoi accélérer tout ça, ne pas constamment demander au kernel une résolution de chemin encore faut-il y avoir accès (donc probablement qu’en C ?) et les connaître. Ça demande une compréhension fine du système, un profiler n’est qu’une aide qui ne répond que, très mal, qu’à une partie du problème. Au mieux du mieux, il te donne une piste sur les bouts de code à optimiser. Mais rien ne garantit que ce bout de code n’est pas tout simplement bon à jeter à la poubelle, au lieu de passer du temps dessus pour grapiller quelques pourcents. Ton truc de modifier la structure de tes répertoires, c’est typique d’une fausse bonne idée : un répertoire c’est juste une liste de fichiers, et une liste de 10k éléments (×ばつ255 octets / noms de fichiers = 2,55Mo) c’est que dalle à l’heure actuelle. Si t’es limité par une aussi petite liste, c’est clairement que y’a une couille dans ton programme (ie. si t’as un problème d’IOs, c’est parce que tu fais des IOs à tort). Quand t’as 16Go de données, oui là tu peux mettre en place une stratégie de segmentation pour traiter par partie...
Pour SQL c’est encore pire. Dans tous les cas il ne faut pas préjuger du facteur limitant d’une application. Dans ma vie, j’ai connu exactement le contraire. Faut dire que j’ai travaillé sur des applis scientifiques (donc totalement limitées par le calcul) et du traitement batch de données dans la banque/assurance (donc masse de SQL en ce qui me concerne), où un problème d’IO a toujours relevé, très clairement, d’une mauvaise conception : car le principe de base dans mon domaine, c’est un accès/traitement/mise-à-jour totalement séquentiel et linéaire des données (l’enjeu sera de dimensionner correctement capacité de calcul et débits, et dans ce cas cela relève des choix de production). Si tu demandes un accès random, tu vas être à la ramasse sur les IOs, mais ton problème n’est absolument pas un problème d'IOs, le problème c’est l’accès random sur xGo de données...
Dans 99% des cas que je rencontre en pratique, c’est codé avec les pieds, avec un modèle physique de données inadapté (je plaide coupable : je normalise systématiquement pour privilégier la maintenance, ce qui multiplie les jointures...) et le compilateur, CPU, n’y peuvent absolument rien. Remet tes données à plat, maintien un journal des mouvements, traités en batch à postériori, comme on peut le faire dans le monde bancaire, tu va voir que les IOs ne seront plus ton (seul) problème. Ouah t’as optimisé un code sous-optimal ? La bonne affaire ! et si je le vire pour faire la même chose de manière autrement plus efficace ?
[^] # Re: Who's that guy ?
Posté par Nicolas . En réponse au lien Software is Way Less Performant Today. Évalué à -2.
La recherche des fichiers n’est pas si consommatrice. La structure des répertoires est très légères et, sauf le premier accès, va être pauvre en IO. Ce qui va se jouer c’est le syscall (permutation user-kernel mode), et les différents algo. en œuvre pour la résolution du chemin, la vérification des droits, etc. Par défaut, par exemple, la liste des fichiers est très souvent triée dans le monde Unix, au lieu d’être restituée dans l’ordre présent sur le disque (± l’ordre dans lequel ça a été écrit). Il y a de quoi accélérer tout ça, ne pas constamment demander au kernel une résolution de chemin encore faut-il y avoir accès (donc probablement qu’en
C?) et les connaître. Ça demande une compréhension fine du système, un profiler n’est qu’une aide qui ne répond que, très mal, qu’à une partie du problème. Au mieux du mieux, il te donne une piste sur les bouts de code à optimiser. Mais rien ne garantit que ce bout de code n’est pas tout simplement bon à jeter à la poubelle, au lieu de passer du temps dessus pour grapiller quelques pourcents. Ton truc de modifier la structure de tes répertoires, c’est typique d’une fausse bonne idée : un répertoire c’est juste une liste de fichiers, et une liste de 10k éléments (×ばつ255 octets / noms de fichiers = 2,55Mo) c’est que dalle à l’heure actuelle. Si t’es limité par une aussi petite liste, c’est clairement que y’a une couille dans ton programme (ie. si t’as un problème d’IOs, c’est parce que tu fais des IOs à tort). Quand t’as 16Go de données, oui là tu peux mettre en place une stratégie de segmentation pour traiter par partie...Pour SQL c’est encore pire. Dans tous les cas il ne faut pas préjuger du facteur limitant d’une application. Dans ma vie, j’ai connu exactement le contraire. Faut dire que j’ai travaillé sur des applis scientifiques (donc totalement limitées par le calcul) et du traitement batch de données dans la banque/assurance (donc masse de SQL en ce qui me concerne), où un problème d’IO a toujours relevé, très clairement, d’une mauvaise conception : car le principe de base dans mon domaine, c’est un accès/traitement/mise-à-jour totalement séquentiel et linéaire des données (l’enjeu sera de dimensionner correctement capacité de calcul et débits, et dans ce cas cela relève des choix de production). Si tu demandes un accès random, tu vas être à la ramasse sur les IOs, mais ton problème n’est absolument pas un problème d'IOs, le problème c’est l’accès random sur xGo de données...
Dans 99% des cas que je rencontre en pratique, c’est codé avec les pieds, avec un modèle physique de données inadapté (je plaide coupable : je normalise systématiquement pour privilégier la maintenance, ce qui multiplie les jointures...) et le compilateur, CPU, n’y peuvent absolument rien. Remet tes données à plat, maintien un journal des mouvements, traités en batch à postériori, comme on peut le faire dans le monde bancaire, tu va voir que les IOs ne seront plus ton (seul) problème. Ouah t’as optimisé un code sous-optimal ? La bonne affaire ! et si je le vire pour faire la même chose de manière autrement plus efficace ?