Comment puis-je améliorer les performances lors de l'ajout d'InDesign XMLElements via AppleScript ?

Question

J'ai un programme AppleScript qui crée des balises et des éléments XML dans un document Adobe InDesign.Les données sont présentées dans des tableaux et le marquage de chaque cellule prend 0,5 seconde.L'ensemble du script prend plusieurs heures.

Je peux publier le code de la boucle interne, mais je ne sais pas si SO est censé être générique ou spécifique.Je vais laisser la foule décider.

Modifier] Le code construit une liste (avant cette boucle) qui contient un élément par ligne dans le tableau.Il existe également une liste contenant une chaîne pour chaque colonne du tableau.Pour chaque cellule, le programme crée un élément XML et une balise XML en concaténant les éléments dans les positions [ligne]/[colonne] des deux listes.Il associe également le texte de cette cellule à l'élément nouvellement créé.

Je suis complètement nouveau sur AppleScript, donc une partie de ce code est grossièrement modifiée à partir des exemples d'Adobe.Si le code est atroce, je ne serai pas offensé.

Voici le code :

repeat with columnNumber from COL_START to COL_END

    select text of cell ((columnNumber as string) & ":" & (rowNumber as string)) of ThisTable

    tell activeDocument

        set thisXmlTag to make XML tag with properties {name:item rowNumber of symbolList & "_" & item columnNumber of my histLabelList}

        tell rootXmlElement

            set thisXmlElement to make XML element with properties {markup tag:thisXmlTag}

        end tell

        set contents of thisXmlElement to (selection as string)

    end tell

end repeat

MODIFIER:J'ai reformulé la question pour mieux refléter la bonne réponse.

Answer 1

J'ai compris celui-ci.

Le document contient un tas de tableaux de données.Au total, environ 7 000 points de données doivent être exportés.Je créais un élément racine avec 7 000 enfants.

Ne fais pas ça.L'ajout de chaque enfant à l'élément racine est devenu de plus en plus lent jusqu'à ce qu'environ 5 000 enfants AppleScript expire et le programme soit abandonné.

La solution consistait à rendre mon code plus fragile en créant environ 480 enfants à partir de la racine, chaque enfant ayant environ 16 petits-enfants.Même nombre de nœuds, mais le code s'exécute désormais assez vite.(Le traitement du document prend encore environ 40 minutes, mais c'est infiniment moins de temps que l'infini.)

Soit dit en passant, le plan initial de 7 000 enfants n’était pas aussi stupide ou paresseux qu’il y paraît.La nouvelle solution m'oblige à relier les deux tables entre elles en utilisant les données des tables que je ne contrôle pas.Le programme sera désormais interrompu s'il reste un espace là où il ne devrait pas y en avoir.(Mais ça marche.)

Answer 2

Le problème vient presque certainement de la sélection.Existe-t-il un moyen d'extraire tout le texte en même temps, puis de parcourir les variables internes ?

Answer 3

Je peux publier le code de la boucle interne, mais je ne sais pas si SO est censé être générique ou spécifique.Je vais laisser la foule décider.

Le code que vous publiez à titre d'exemple peut être aussi spécifique que vous (ou votre patron) êtes à l'aise - le plus souvent, il est plus facile de vous aider avec des détails plus spécifiques.

Answer 4

Si le code de la boucle interne est d'une longueur raisonnable, je ne vois aucune raison pour laquelle vous ne pouvez pas le publier.Je pense que Stack Overflow est destiné à englober des questions à la fois générales et spécifiques.

Answer 5

Utilisez-vous InDesign ou InDesign Server ?Combien de pages fait votre document (ou quelles autres informations pouvez-vous nous fournir sur la configuration de votre document/ID) ?

Je fais beaucoup de développement InDesign Server.Vous pourriez constater des ralentissements pour plusieurs raisons qui ne sont pas nécessairement liées au code.

À l'heure actuelle, je génère des documents de 100 à 300 pages presque entièrement à partir d'un script/xml en 100 secondes environ (vous faites peut-être quelque chose de beaucoup plus volumineux).