#33 closed task (fixed)
Measure the impact of filling stack trace information when performing GO/RETURN/THROW
| Reported by: | vvoutilainen | Owned by: | somebody |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.22 |
| Component: | other | Version: | 1.0 |
| Keywords: | exception ConditionThrowable go return throw performance | Cc: | |
| Parent Tickets: |
Description (last modified by )
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.
Attachments (1)
Change History (3)
Changed 16 years ago by
| Attachment: | ConditionThrowable.java.stacktrace.diff added |
|---|
comment:1 Changed 16 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.
comment:2 Changed 14 years ago by
| Description: | modified (diff) |
|---|---|
| Milestone: | unscheduled → 0.22 |
closed is not 'unscheduled'; moving to the most recently closed milestone.
A patch candidate for removing stack trace information generation on ConditionThrowable? instantiation.