Dans mon précédent blog À propos des données iTunes, j’ai montré un simple programme JSL (JMP Scripting Language) pour analyser le fichier XML iTunes. J'ai terminé la publication en me demandant si le code fonctionnerait correctement dans mon fichier complet iTunes Library.xml de 13,3 Mo.
Le programme JSL s’est exécuté en moins d’une seconde sur mon fichier de test de 7 Ko. Combien de temps a-t-il fallu pour l'ensemble des 13,3 Mo? Cela a pris 90 secondes. Où était le temps passé? La réponse à cette question est au centre de cet article, qui fait partie de la deuxième partie d'une série sur mon projet de collecte de données iTunes.
Comment améliorer facilement les performances de mon script?
Avant JMP 11, ce n'était pas une question facile à répondre. JMP 11 a introduit le JSL Profiler . C'est un excellent outil pour évaluer les domaines dans lesquels un programme de JSL passe du temps, ligne par ligne.
Pour utiliser le profileur JSL, j'ai cliqué sur l'icône «Script de débogage» en haut de l'éditeur JSL, puis sur l'icône «minuterie» pour mettre le débogueur en mode profileur. L'exécution de mon script sur le fichier complet de 13,3 Mo a montré que le code passait tout son temps dans la ligne d'analyse XML, qui inclut la commande Ajouter une ligne (). Je suppose que la plupart du temps est passé à mettre à jour l'état de la table.
Le rapport de profileur JSL dans JMP
J'ai réalisé que je pouvais ajouter un message JSL à la table de données pour retenir tous les messages de mise à jour. Le message est:
dt << Commencer la mise à jour des données;
À la fin de la table de données traitant le message, il faudrait ajouter ceci:
dt << Fin de la mise à jour des données;
Après l’ajout de ces messages, le programme n’a pris que 13 secondes au lieu de 90 secondes, soit une réduction de 85% du temps de traitement!
Maintenant, je dois nettoyer certaines des données que je ne souhaite pas pour mon analyse. Mes données contiennent de nombreux enregistrements détaillant les pistes faisant partie des listes de lecture. Je dois ajouter du code à ma JSL pour ne pas traiter les balises contenant des données de liste de lecture. Selon mes données, cela représentait environ 10% du total.
Données de la liste de lecture iTunes
Merci au développeur JMP Michael Hecht pour suggérer le code suivant que j'ai ajouté à la JSL. Désormais, toutes les balises «clés» ayant «Playlist» en tant que valeurs de texte n'étaient pas traitées en tant que données.
OnElement (
"clé",
Balise de fin (
txt = XML Text ();
Si(
étiquette de processus,
Si(
txt == "Playlists", balise de processus = 0,
Est manquant (Num (txt)),
raw dt << Ajouter des lignes (1);
raw dt: Key [Row ()] = txt;
),
txt == "Tracks", balise de processus = 1
)
)
)
Vous pouvez télécharger mon Programme JSL à partir de l’échange de fichiers JMP et étudiez vos propres données iTunes. (Le téléchargement nécessite un Communauté d'utilisateurs JMP Compte.)
Je vais sauvegarder l'analyse complète des données de mon dernier message, mais je vais vous en donner un aperçu. Ci-dessous un Treemap montrant mon écoute par genre et artiste. J'adore Bruce Springsteen et j'ai «forcé» mes enfants à l'écouter beaucoup au fil des ans, en les emmenant même à de nombreux concerts. J'aime aussi l'opéra, le jazz et le blues. Comme vous pouvez le constater, j'adore la musique.
Treemap of Play Count par genre et artiste à l'aide de la plate-forme JMP Treemap.
