Log:
allegement de l'empreinte memoire de l'espace prive :
- pas de favicon calculee, c'est trop consommateur
- filtres_images est devenu enorme, alors qu'on utiliser que image_reduire dans ecrire/. On le separe en deux. Pour les squelettes, pas de soucis le compilateur gere, pour les appels directs des plugins, attention a bien inclure filtres_images_etendus si necessaire
Le 8 déc. 08 à 16:19, cedric@yterium.com a écrit :
- filtres_images est devenu enorme, alors qu'on utiliser que image_reduire dans ecrire/. On le separe en deux. Pour les squelettes, pas de soucis le compilateur gere,
hum. Je ne peux plus me loger dans l'espace privé:
Le 8 déc. 08 à 16:19, cedric@yterium.com a écrit :
- filtres_images est devenu enorme, alors qu'on utiliser que image_reduire dans ecrire/. On le separe en deux. Pour les squelettes, pas de soucis le compilateur gere,
hum. Je ne peux plus me loger dans l'espace privé:
filtre « couleur_foncer » non défini
dans prive/style_vieilles_def dit le log
Committo,Ergo:Sum
J'ai aussi un problème... qui est apparu en désactivant spip-bonux pour tester justement : la CSS privée (sans spip bonux qui l'allège) calcule des images avec la fonction image_bg() qui appelle : le filtre image_aplatir() lui même ayant été transporté dans filtres_images_etendus.php . Du coup, la fonction n'est pas trouvée car l'include n'est pas fait.
Mais si j'ajoute l'include... bien... ça reviendrait au même qu'avant le découpage en 2 du fichier...
Le 8 déc. 08 à 18:22, Matthieu Marcillaud a écrit :
Emmanuel Saint-James a écrit :
Le 8 déc. 08 à 16:19, cedric@yterium.com a écrit :
- filtres_images est devenu enorme, alors qu'on utiliser que image_reduire dans ecrire/. On le separe en deux. Pour les squelettes, pas de soucis le compilateur gere,
hum. Je ne peux plus me loger dans l'espace privé:
filtre « couleur_foncer » non défini
dans prive/style_vieilles_def dit le log
Committo,Ergo:Sum
J'ai aussi un problème... qui est apparu en désactivant spip-bonux pour tester justement : la CSS privée (sans spip bonux qui l'allège) calcule des images avec la fonction image_bg() qui appelle : le filtre image_aplatir() lui même ayant été transporté dans filtres_images_etendus.php . Du coup, la fonction n'est pas trouvée car l'include n'est pas fait.
Mais si j'ajoute l'include... bien... ça reviendrait au même qu'avant le découpage en 2 du fichier...
oui dans ce cas précis, mais la css etant calculée hors de l'espace privé lorsque la mémoire n'est pas suffisante, cela n'est pas critique.
Que fait-on donc ?
Il faut donc inclure dans image_bg()
On revient en arrière, parce qu'il était dit que pour une RC on ne fait que corriger des bugs, pas en introduire.
Le commit qui fait mal n'a pas été fait pour le plaisir, mais suite aux nombreux reports de bugs 'page blanche après installation et login'
Certains de ces reports étaient dus a l'upgrade par spip_loader, qui concervait les vieux fichiers de la dist/, ce qui a été corrigé en renommant en squelettes-dist/
D'autres de ces reports étaient dus à la limite de 8Mo qui ne permettait meme pas d'afficher la page d'accueil de l'espace privé.
Cela m'a conduit à identifier les grosses sources de consommation mémoire. J'ai trouvé :
- les appels à filtres_images, fichier qui a beaucoup grossi
- le favicon calculé faisant appel a un image recadre -> supprimé au profit du favicon statique
- le reste des appels de l'espace privé étant uniquement du type image_reduire (le filtre originel de SPIP qui a donné naissance à toute la librairie par la suite), j'ai découpé inc/filtres_images en 2 morceaux inégaux, le plus petit étant suffisant pour les traitements faits dans l'espace privé.
Si vous préférez, on peut revenir à l'ancienne version de inc/filtres_images, avec les impacts que cela a.
Cédric
Si vous préférez, on peut revenir à l'ancienne version de
inc/filtres_images, avec les impacts que cela a.
Ca risque d'être pénible
Il y a malheureusement trop d'hébergements réglés sur 8Mo, je crois
que c'est bien d'essayer de rester en-dessous. En faisant maigrir SPIP
on peut y arriver.
Le 8 déc. 08 à 19:10, cedric.morin@yterium.com a écrit :
Le 8 déc. 08 à 18:22, Matthieu Marcillaud a écrit :
Emmanuel Saint-James a écrit :
Le 8 déc. 08 à 16:19, cedric@yterium.com a écrit :
- filtres_images est devenu enorme, alors qu'on utiliser que image_reduire dans ecrire/. On le separe en deux. Pour les squelettes, pas de soucis le compilateur gere,
hum. Je ne peux plus me loger dans l'espace privé:
filtre « couleur_foncer » non défini
dans prive/style_vieilles_def dit le log
Committo,Ergo:Sum
J'ai aussi un problème... qui est apparu en désactivant spip-bonux pour tester justement : la CSS privée (sans spip bonux qui l'allège) calcule des images avec la fonction image_bg() qui appelle : le filtre image_aplatir() lui même ayant été transporté dans filtres_images_etendus.php . Du coup, la fonction n'est pas trouvée car l'include n'est pas fait.
Mais si j'ajoute l'include... bien... ça reviendrait au même qu'avant le découpage en 2 du fichier...
oui dans ce cas précis, mais la css etant calculée hors de l'espace privé lorsque la mémoire n'est pas suffisante, cela n'est pas critique.
Que fait-on donc ?
Il faut donc inclure dans image_bg()
On revient en arrière, parce qu'il était dit que pour une RC on ne fait que corriger des bugs, pas en introduire.
Le commit qui fait mal n'a pas été fait pour le plaisir, mais suite aux nombreux reports de bugs 'page blanche après installation et login'
Certains de ces reports étaient dus a l'upgrade par spip_loader, qui concervait les vieux fichiers de la dist/, ce qui a été corrigé en renommant en squelettes-dist/
D'autres de ces reports étaient dus à la limite de 8Mo qui ne permettait meme pas d'afficher la page d'accueil de l'espace privé.
Cela m'a conduit à identifier les grosses sources de consommation mémoire. J'ai trouvé :
- les appels à filtres_images, fichier qui a beaucoup grossi
- le favicon calculé faisant appel a un image recadre -> supprimé au profit du favicon statique
- le reste des appels de l'espace privé étant uniquement du type image_reduire (le filtre originel de SPIP qui a donné naissance à toute la librairie par la suite), j'ai découpé inc/filtres_images en 2 morceaux inégaux, le plus petit étant suffisant pour les traitements faits dans l'espace privé.
Si vous préférez, on peut revenir à l'ancienne version de inc/filtres_images, avec les impacts que cela a.
Cédric
Ah, je n'y pense que maintenant, mais sans doute aurait-il été plus judicieux de faire le contraire :
un filtres_images_mini, et un filtres_images
en remplacant tous les appels dans ecrire/ vers filtres_images_mini.
Cela aurait évité de cassé la compatibilité des inclusions a filtres_images.
Il y a malheureusement trop d'hébergements réglés sur 8Mo, je crois
que c'est bien d'essayer de rester en-dessous. En faisant maigrir SPIP
on peut y arriver.
Soit, mais SVP tester avant d'envoyer.
Et j'aimerais bien que le bug de la redirection du login déjà fait soit corrigé, c'est plus prioritaire de corriger des régression que d'améliorer les perfs.
un filtres_images_mini, et un filtres_images
en remplacant tous les appels dans ecrire/ vers filtres_images_mini.
Cela aurait évité de cassé la compatibilité des inclusions a filtres_images.
oui; inc/filtres est aussi découpé comme ça avec un inc/filtres_mini
Le 8 déc. 08 à 19:19, Emmanuel Saint-James a écrit :
Le 8 déc. 08 à 19:14, Fil a écrit :
Il y a malheureusement trop d'hébergements réglés sur 8Mo, je crois
que c'est bien d'essayer de rester en-dessous. En faisant maigrir SPIP
on peut y arriver.
Soit, mais SVP tester avant d'envoyer.
Et j'aimerais bien que le bug de la redirection du login déjà fait soit corrigé, c'est plus prioritaire de corriger des régression que d'améliorer les perfs.
Il ne s'agissait pas de perf mais d'un brutal 'page blanche' y compris dans la configuration par défaut de MAMP. Pas vraiment mineur comme problème, et je crois qu'on peut aussi considérer cela comme une régression.
Ca m'a pris la journée, que j'aurais largement préféré l'employer autrement.