[ https://issues.apache.org/jira/browse/TAP5-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14158778#comment-14158778 ]
ASF subversion and git services commented on TAP5-2333: ------------------------------------------------------- Commit 1cb63a12b4887b54210d91fe4a9863cf3dad93b5 in tapestry-5's branch refs/heads/master from [~hlship] [ https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;h=1cb63a1 ] TAP5-2333: Optimize OperationTracker logging for normal (success, no logging) case This avoids the use of a per-thread variable. > Decrease number of ThreadLocal.get calls > ---------------------------------------- > > Key: TAP5-2333 > URL: https://issues.apache.org/jira/browse/TAP5-2333 > Project: Tapestry 5 > Issue Type: Improvement > Reporter: Michael Mikhulya > Labels: performance > Fix For: 5.4 > > Attachments: > 0001-TAP5-2333-Decrease-number-of-ThreadLocal.get-calls.patch, > 0002-TAP5-2333-Decrease-number-of-ThreadLocal.get-calls.patch, > 0003-TAP5-2333-Decrease-number-of-ThreadLocal.get-calls.patch > > > During profiling I found that ThreadLocal.get is a very hot method call. > Most frequently it is called from PerThreadOperationTracker. > PerThreadOperationTracker can be replaced with SimpleOperationTracker which I > introduced in a patch. > SimpleOperationTracker only prints exception without "operations trace". > "Operations trace" can be useful during debug. So in my patch > PerThreadOperationTracker is used in debug mode, but otherwise > SimpleOperationTracker is used. > Please check whether this decision is good for most cases. > Performance gains are very serious. > Time per request decreased on 11ms (23% of overall time). > All measurements are done with apache benchmark after warm up phase. > Currently my patch breaks two tests: > CoreBehaviorsTests. event_handler_return_types > MiscTests. operation_tracking_via_annotation > Both tests are broken because tests depend on 'Operation description' which > is ignored by SimpleOperationTracker. > The simplest way to fix tests is to enforce using PerThreadOperationTracker > for these tests. > I'm not sure whether 'Operation description' is definitely useful especially > taking into account that only 2 tests become broken. We use > SimpleOperationTracker on production for several months already and nobody > notice that 'Operation descriptions' are absent. In all cases (for us) it was > enough to see a stack trace of exception in logs. > See TAP5-2332. There is a huge amount of String.format required to track such > 'operation descriptions'. By removing calculation of such 'operation > descriptions' Tapestry can be made much faster. > If 'Operation descriptions' is required for some cases than we can introduce > some option to enable/disable this feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)