Re: Les limites mémoires de LilyPond

[Seventies]

Merci de vos réactions.

Effectivement, le problème ne se pose pas dans l'immédiat puisque, pour la
directrice comme pour les parties, les fichiers d'entrée sont très courts.
Il faut donc quelques secondes pour désactiver un ou plusieurs des quatre
mouvements.

Ici, contrairement aux travaux précédents, je désire présenter une
directrice de type professionnelle, c'est à dire une portée par instrument
(deux portées pour les flûtes, quatre pour les cors ...), et au format B4.

Comme les fichiers sont très bien structurés, grâce aux variables et aux
tags, il a suffit de quatre soirées pour réaliser cette partition. 214
pages, mais comme dans tout concerto, énormément de vides.

Mais la compilation utilise 1850 Mo, contre 1310 Mo pour la directrice
classique (vents groupés par deux).

Qui plus est, j'ai réalisé quelques tests, pour constater que d'autres
applications peuvent tourner en même temps. Là, c'est Windows qui gère la
mémoire virtuelle, et les applications inactives sont reportées vers cette
mémoire.

Il est même possible de compiler simultanément deux gros fichiers LilyPond :
ils sont considérés comme processus indépendants, et Windows gère lui-même
l'échange de la mémoire. Au pire, le temps de calcul est triplé, voire
décuplé, car la majorité du temps de calcul est réservé aux échanges.

Par contre, si la partition LilyPond devient plus importante, ça coince :
j'ai dédoublé, le temps d'un test, le dernier mouvement, et là, ça n'est pas
passé :
"This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
This object should be a markup: ()"

N'étant pas spécialiste de la mémoire virtuelle, j'ai tout de même jeté un
œil sur ce procédé, et visiblement, les applications doivent spécifier, lors
de l'allocation mémoire, si le bloc alloué doit rester ou non en mémoire
physique. Et le maintient semble être l'option par défaut.

En résumé donc :
- d'autres processus peuvent tourner simultanément sans trop de problème,
- LilyPond possède bien une limite au delà de laquelle la compilation
échoue.

J'ai fait de la programmation dans ma jeunesse, mais je ne suis plus capable
de donner aucun conseil.
Toutefois, dans certaines applications gourmandes en mémoire, la solution
était de surveiller la mémoire disponible, et en cas de manque, d'envoyer
des blocs de donnée dans des fichiers temporaires. Plus facile à dire qu'à
faire, il faut souvent revoir les bases même de l'application.

Alors, peut-être une solution pour la 2.22 ? ;-)

Cordialement,

Jean-François



--
View this message in context: 
http://lilypond-french-users.1298960.n2.nabble.com/Les-limites-memoires-de-LilyPond-tp7582325p7582331.html
Sent from the LilyPond French Users mailing list archive at Nabble.com.