Bug #465

Performance Bottleneck: expensive/frequent construction of UUID objects

Added by M. Rolf almost 13 years ago. Updated almost 13 years ago.

Status:ResolvedStart date:08/01/2011
Priority:NormalDue date:
Assignee:J. Moringen% Done:

100%

Category:C++
Target version:0.4

Description

UUID contruction from Event->MetaData consumes too much time within spread::ReceiverTask::notifyHandler
is it necessary too call expensive random-number generation each time?

see Ticket #464 for profiler output
#464 and this one consume about 80% of the CPU-time in spread::ReceiverTask::notifyHandler

event_creation.cc Magnifier - test program (224 Bytes) J. Moringen, 08/01/2011 08:10 PM

Makefile - for building test program (211 Bytes) J. Moringen, 08/01/2011 08:10 PM

Related issues

Related to Robotics Service Bus - Enhancement #429: Reduce event creation cost Resolved 07/20/2011

Associated revisions

Revision bddf50d0
Added by J. Moringen almost 13 years ago

Avoid unconditional creation of random sender id in src/rsb/MetaData.cpp
fixes #465
  • src/rsb/MetaData.cpp: use nil UUID constructor to create default
    value of sender id
  • test/rsb/HandlerTest.cpp: manually supply random sender ids to
    maintain previous behavior
  • test/rsb/MetaDataTest.cpp: likewise
  • test/rsb/eventprocessing/ParallelEventReceivingStrategyTest.cpp:
    likewise

History

#1 Updated by J. Moringen almost 13 years ago

  • Status changed from New to In Progress
  • Assignee set to J. Moringen
  • Target version set to 0.4

#2 Updated by J. Moringen almost 13 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset r2198.

#3 Updated by J. Moringen almost 13 years ago

The attached test program gives the following results:

Before r2198:

/tmp $ time ./event_creation 
20.065 secs

After r2198:
/tmp $ time ./event_creation 
4.891 secs

#4 Updated by J. Moringen almost 13 years ago

  • Status changed from Resolved to Feedback

#5 Updated by M. Rolf almost 13 years ago

works fine.

#6 Updated by J. Moringen almost 13 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF