-
Notifications
You must be signed in to change notification settings - Fork 809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ExecuteTime] A way to clear timing results is needed #1021
Comments
Yes, this sounds like a good idea, and easy to achieve. For me, I think i wouldn't want timings cleared, but it's equally easy to make this a configurable behaviour, so I can add that too, I should think. Feel free to make a PR if you've time/inclination, otherwise I'll get around to it when I have a chance :) |
@jcb91 I won't have time to dive into the internals of ExecuteTime and solve this myself anytime soon. Any kind of solution would be appreciated, since I will be using Jupyter notebooks in a number of screencasts that I am preparing, and I would like to start each screencast with a truly empty notebook. The ability to clear timing results is also useful when you are handing out a notebook to students for doing some homework exercises. Any timing results left over from previous runs that you did yourself are noise (or plain giveaways as to the expected efficiency). Currently, I use a script that I wrote to delete all metadata for a given key. But that is somewhat cumbersome. |
By the way, here is another reason for wanting to clear timing results. When you keep your notebooks in a repository (for configuration management, e.g. using Git), Reason: Changes in the notebook may cause changes in the output, and those output changes would pollute diffs. When execution timings are committed as well, you still get noise in your diffs, since these timings change with each rerun. That is also why it would be convenient to have the ability to clear timing results along with removal of output. For instance, when you do Kernel > Restart & Clear Output. |
Oh sure, there's definitely reasons for doing it! I've added menu items ok, I think. My plan to now has been to give a configurable option along the lines of "clear timings on kernel restart", which will automatically apply. Would you prefer to add another option to the kernel menu (eg. |
A configurable option “clear timings on kernel restart” would be wonderful for me. It would simplify my workflow considerably, both for screen casting and configuration management.
My comment was mainly ‘for the record’; not to convince or pressure you more.
Thanks for looking into this so quickly.
… On 19 Jul 2017, at 12:38, Josh Barnes ***@***.***> wrote:
Oh sure, there's definitely reasons for doing it! I've added menu items ok, I think. My plan to now has been to give a configurable option along the lines of "clear timings on kernel restart", which will automatically apply. Would you prefer to add another option to the kernel menu (eg. Kernel > Restart & Clear Output & Timings, or another configurable setting to make the nbextension clear timings when choosing the existing Kernel > Restart & Clear Output?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Ok, I've made a stab at a PR which provides both menu items to clear selected/all cells' timing data, and configurable options to also clear all cells' data on kenrel restart, or clear any cell's data when its outputs are cleared (which would cover use of |
This issue concerns the ExecuteTime extension.
Currently, there seems to be no way to clear selected or all timing results. You can only hide them.
Sometimes (e.g., when giving a presentation), you do want to see the timings, but you want to start with a clean slate (and not show timing results of an earlier run).
It seems reasonable that restarting the kernel clears the timing results.
If that is not possible or not desirable, then an extra menu item would be welcome.
Of course, it is possible to achieve this clearing with an external script, but that seems unnecessarily cumbersome.
The text was updated successfully, but these errors were encountered: