[armedbear-ticket] [armedbear] #33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW
#33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW ----------------------------------------------------------------------+----- Reporter: vvoutilainen | Owner: somebody Type: task | Status: new Priority: minor | Milestone: unscheduled Component: component1 | Version: 1.0 Keywords: exception ConditionThrowable go return throw performance | ----------------------------------------------------------------------+----- Douglas R. Miles reported recently that java.lang.Throwable.fillInStackTrace() can be a very time consuming operation when instantiating Throwables or objects the class of which extends Throwable.
A patch for overriding the fillInStackTrace() function with an empty implementation was created, it seems to be a performance gain, but a benchmark is required. ANSI tests test so many other things that it's difficult to compare the impact of the patch without a test that tests only GO/RETURN/THROW.
#33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW ---------------------------+------------------------------------------------ Reporter: vvoutilainen | Owner: somebody Type: task | Status: closed Priority: minor | Milestone: unscheduled Component: component1 | Version: 1.0 Resolution: fixed | Keywords: exception ConditionThrowable go return throw performance ---------------------------+------------------------------------------------ Changes (by vvoutilainen):
* status: new => closed * resolution: => fixed
Comment:
Douglas R. Miles kindly did the measurement by using cl-bench, http://www.cliki.net/Performance%20Benchmarks. The benchmark CTAK showed a huge improvement, so the patch was decided to be good enough to commit. If some developer needs to have stack trace information in GO/RETURN/THROW, the fillInStackTrace override needs to be locally commented out in ConditionThrowable.java.
Committed in r11412.
#33: Measure the impact of filling stack trace information when performing GO/RETURN/THROW ---------------------------+------------------------------------------------ Reporter: vvoutilainen | Owner: somebody Type: task | Status: closed Priority: minor | Milestone: 0.22 Component: other | Version: 1.0 Resolution: fixed | Keywords: exception ConditionThrowable go return throw performance ---------------------------+------------------------------------------------ Changes (by ehuelsmann):
* milestone: unscheduled => 0.22
Old description:
Douglas R. Miles reported recently that java.lang.Throwable.fillInStackTrace() can be a very time consuming operation when instantiating Throwables or objects the class of which extends Throwable.
A patch for overriding the fillInStackTrace() function with an empty implementation was created, it seems to be a performance gain, but a benchmark is required. ANSI tests test so many other things that it's difficult to compare the impact of the patch without a test that tests only GO/RETURN/THROW.
New description:
Douglas R. Miles reported recently that java.lang.Throwable.fillInStackTrace() can be a very time consuming operation when instantiating Throwables or objects the class of which extends Throwable.
A patch for overriding the fillInStackTrace() function with an empty implementation was created, it seems to be a performance gain, but a benchmark is required. ANSI tests test so many other things that it's difficult to compare the impact of the patch without a test that tests only GO/RETURN/THROW.
--
Comment:
closed is not 'unscheduled'; moving to the most recently closed milestone.
armedbear-ticket@common-lisp.net
-
armedbear