2010-07-12 4 views
12

F # Interactive (et en général les outils de style REPL) est une entrée idéale pour le profilage des performances. Quoi de plus simple que de sélectionner un bloc de code et de l'envoyer directement à un profileur qui reviendrait avec un rapport d'analyse de performance. Malheureusement, il semble que les profileurs existants ne disposent pas de support REPL: vous devez soit attacher un profileur à un processus ou spécifier et exécuter ou application Web à profiler. Ce que je finis par faire est alors d'encapsuler un bloc de code à profiler dans un test unitaire, puis d'exécuter un profil par rapport à la session en ligne de commande NUnit. Mais est-ce le meilleur que nous pouvons faire maintenant avec F #?Profileurs interactifs et de performance F #

+0

J'ai posté une question dans le forum RedGate ANTS Profiler, et ils ont dit qu'ils ont aimé l'idée et qu'ils la considéreraient. –

+0

Il y a une autre façon de penser au profilage - non pas en mesurant le temps et en comptant les appels, mais en demandant «Que diable fait-il? - http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343 –

Répondre

9

Quelle est la question?

Connaissez-vous la commande #time? Par exemple.

#time "on" 
for i in 1..1000000 do 
    let r = f(i) 
    ignore r 

qui donne F # sortie interactive comme

--> Timing now on 
Real: 00:00:00.000, CPU: 00:00:00.000, GC gen0: 0, gen1: 0, gen2: 0 

Dans tous les cas, je pense que mettre simplement le code dans une application et l'exécution du profil contre l'application est mieux que un test NUnit. Quoi qu'il en soit, oui, il vous en coûtera peut-être 30 secondes de plus pour coller le code dans une nouvelle application et le compiler en mode édition. Mais c'est un prix que je suis prêt à payer pour obtenir les informations de profilage riches fournies par Visual Studio. Idéalement, l'expérience pourrait être meilleure, mais je doute que vous trouverez des outils de profilage REPL-friendly aujourd'hui (ou demain).

+0

Oui, mais cela n'est utile que dans des cas simples. Cela ne vous donne pas une image de la répartition du temps d'exécution entre les opérations dans la pile d'appels. –

+0

Et pour répondre à votre question "quelle est la question?": La question n'est pas de chronométrer l'exécution d'un appel externe. La question concerne le profilage des performances qui va bien au-delà: c'est une analyse de performance complète basée sur les données de performance collectées.Les profileurs de performances modernes tels que dotTrace et ANTS peuvent le faire en se connectant à un processus ou en exécutant une application, mais ce serait très efficace s'ils pouvaient profiler le code envoyé à F # Interactive. La question était donc de savoir si cela pouvait être réalisé. –

+0

Je ne connaissais pas la commande #time! –

4

Vous pouvez essayer d'utiliser l'API programmeur du profileur pour y parvenir. Je ne l'ai pas essayé, mais voici les instructions pour l'ANTS profileur: http://help.red-gate.com/help/ANTSProfiler3/0/en/Topics/AP_UsingTheAPI.html

Je pense que les mesures suivantes pourraient réussir:

  1. Démarrer ANTS profileur et attacher à fsi.exe
  2. r « Redgate. Profiler.Api.dll » dans fsi

  3. Saupoudrez le code que vous voulez avec le profil RedGate.Profiler.Api.Reset()/RedGate.Profiler.Api.TakeSnapshot()

DotTrace a (eu?) API similaire (CPUProfiler.Start() /. StopAndTakeSnapshot()), mais je n'ai pas trouvé les références pour les dernières versions.

+0

C'est une option intéressante! Merci de me le faire savoir. Je vais l'essayer. –

1

Mais est-ce le meilleur que nous pouvons faire maintenant avec F #?

AFAIK, oui. C'est une excellente idée pour une fonctionnalité dans la prochaine version de F # ou un produit tiers bien que!