traceback: formatting a traceback stats the filesystem

[rbtcollins]

BPO	23273
Nosy	@rbtcollins

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2015-01-19.17:55:08.429>
labels = []
title = 'traceback: formatting a traceback stats the filesystem'
updated_at = <Date 2015-01-19.17:55:08.429>
user = 'https://github.com/rbtcollins'

bugs.python.org fields:

activity = <Date 2015-01-19.17:55:08.429>
actor = 'rbcollins'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2015-01-19.17:55:08.429>
creator = 'rbcollins'
dependencies = []
files = []
hgrepos = []
issue_num = 23273
keywords = []
message_count = 1.0
messages = ['234318']
nosy_count = 1.0
nosy_names = ['rbcollins']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue23273'
versions = []

[rbtcollins]

Discovered in bpo-17911, all the traceback calls that render a stack trace end up calling linecache.checkcache, which stats files on disk, making getting a traceback rather more expensive than folk may expect. For "oops, it crashed" situations thats fine, but when used to gather diagnostic details like tulip does, it becomes substantially more wasteful. Since we know when we've reloaded a module, there should be no need to go out to disk at any other time - particularly since if we *haven't* reloaded the module, doing so will just end up showing the wrong source.

Further, PEP-302 source code isn't refreshed when the cache is checked, which can lead to stale code in modules that *have* been reloaded.