Enhancement #540

Scope comparison still expensive

Added by Anonymous over 12 years ago. Updated over 10 years ago.

Status:ClosedStart date:09/03/2011
Priority:NormalDue date:
Assignee:S. Wrede% Done:

40%

Category:Performance OptimizationEstimated time:2.00 hours
Target version:rsb-0.10

Description

Scope comparison proved to be still expensive, when profiling RSB in some examples. Strategy for implementation:

  1. Per-participant caching of Scope objects and referencing of this Scope object via shared pointers, e.g., in notifications. This is necessary as otherwise Event notifications that are kept longer than the lifetime of a participant would contain invalid references. The expectation is that after this change the caching operation will eventually be effective.
  2. Interning across differerent participants in the same process.

A further performance improvement could be to replace the stringbuffer construction of the Scope string with a strcpy variant.

Associated revisions

Revision 7048b49f
Added by S. Wrede over 12 years ago

better handling of Scopes in Informers, refs #540

Revision 872bd51f
Added by Arne Nordmann over 12 years ago

Performance improvements in toString:
  • Return scopestring and components as reference
  • Faster creation of scopestring
    refs #540

Revision bb2af9a5
Added by J. Wienke over 12 years ago

make the scope ptr optimization backwards compatible by introducing a separate method getScopePtr with the new semantics.

refs #540

History

#1 Updated by J. Moringen over 12 years ago

It probably depends on the particular usage patterns, but maybe the concept of interning could be used: if creation is (or can be made into) an infrequent operation, equality comparison would reduce to a single pointer comparison.

This technique is aleady used in cl-rsb when scopes are used as keys in associative containers.

#2 Updated by S. Wrede over 12 years ago

  • Category changed from C++ to Performance Optimization

#3 Updated by S. Wrede over 12 years ago

Also check that the copy constructor actually copies the cache object.

#4 Updated by S. Wrede over 12 years ago

  • Description updated (diff)
  • Assignee set to S. Wrede
  • Target version set to rsb-0.10
  • Estimated time changed from 1.00 to 2.00

#5 Updated by S. Wrede over 12 years ago

  • % Done changed from 0 to 40

Event now stores a ScopePtr (currently a shared_ptr). The participant's ScopePtr is now copied when new Events are constructed upon call to publish. Added also some convenience functions to work with scope values in Event.h.

#6 Updated by J. Wienke almost 12 years ago

Is there any reason that this issue is still open?

#7 Updated by J. Moringen over 10 years ago

  • Status changed from Feedback to Closed

Reopen if this problem surfaces again.

Also available in: Atom PDF