From david.thompson at kitware.com Tue Aug 11 11:38:33 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Aug 2015 11:38:33 -0400 Subject: [Smtk-developers] Attribute callback benchmarks Message-ID: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> Hi all, I am working on adding callbacks to notify applications when attributes are changed. One of the concerns has been the overhead of callbacks on value change events, since these could conceivably happen frequently. I've done some preliminary benchmarking to quantify the cost of calling C++ lambdas each time an attribute value changes. The results are below. To benchmark the timing, I create an attribute with a single DoubleItem and repeatedly change the value of the DoubleItem to a random number. The timings were done on my MacBookPro running Mac OS X 10.9. Without any changes to SMTK: 1. Baseline: 0.355 +/- 0.01 usec per setValue() call. With callback code added: 2. No callbacks registered: 1.238 +/- 0.01 usec per setValue() call. 3. With 1000 empty callbacks: 21.32 +/- 0.20 usec per setValue() call. 4. With 1 trivial callback: 1.281 +/- 0.02 usec per setValue() call. These times were averaged over 5-6 runs, with each run consisting of 1-million setValue calls (except for the version with 1000 callbacks registered, which used 100,000 setValue calls per run). I have not evaluated signal/slot libraries; the callback code uses smtk::function to hold references to callbacks. David From david.thompson at kitware.com Tue Aug 11 14:29:00 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Aug 2015 14:29:00 -0400 Subject: [Smtk-developers] Attribute callback benchmarks In-Reply-To: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> References: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> Message-ID: <156C073D-A560-44A9-977D-F002B1242C2F@kitware.com> To follow up, 1. The timings in my original message were from a debug build (doh!). For a release build, the ratio of time spent is similar but the times are smaller (nanoseconds not microseconds): Without any changes to SMTK: a. Baseline: 131 +/- 7 nsec per setValue() call. With callback code added: b. No callbacks registered: 340 +/- 6 nsec per setValue() call. c. With 1000 empty callbacks: 2533 +/- 22 nsec per setValue() call. d. With 1 trivial callback: 342 +/- 7 nsec per setValue() call. So, subtracting the apparent per-setValue cost (340 nsec) from the 1000-empty-callback version and dividing by 1000, it looks like 2.2 nsec per callback. 2. At least one signal-slot library I wanted to consider was SimpleSignal: https://testbit.eu/cpp11-signal-system-performance/ David On Aug 11, 2015, at 11:38 AM, David Thompson wrote: > Hi all, > > I am working on adding callbacks to notify applications when attributes are changed. One of the concerns has been the overhead of callbacks on value change events, since these could conceivably happen frequently. I've done some preliminary benchmarking to quantify the cost of calling C++ lambdas each time an attribute value changes. The results are below. > > To benchmark the timing, I create an attribute with a single DoubleItem and repeatedly change the value of the DoubleItem to a random number. The timings were done on my MacBookPro running Mac OS X 10.9. > > Without any changes to SMTK: > 1. Baseline: 0.355 +/- 0.01 usec per setValue() call. > With callback code added: > 2. No callbacks registered: 1.238 +/- 0.01 usec per setValue() call. > 3. With 1000 empty callbacks: 21.32 +/- 0.20 usec per setValue() call. > 4. With 1 trivial callback: 1.281 +/- 0.02 usec per setValue() call. > > These times were averaged over 5-6 runs, with each run consisting of 1-million setValue calls (except for the version with 1000 callbacks registered, which used 100,000 setValue calls per run). > > I have not evaluated signal/slot libraries; the callback code uses smtk::function to hold references to callbacks. > > David From david.thompson at kitware.com Tue Aug 11 17:03:33 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Aug 2015 17:03:33 -0400 Subject: [Smtk-developers] Attribute callback benchmarks In-Reply-To: <156C073D-A560-44A9-977D-F002B1242C2F@kitware.com> References: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> <156C073D-A560-44A9-977D-F002B1242C2F@kitware.com> Message-ID: <04E878BB-FAC5-4EA7-A713-2F19428A7A7F@kitware.com> Hi all, In a continuing series of followups, I've been able to reduce the initial overhead of a callback to within a few nanoseconds of nothing by eliminating overhead from the construction of the event object and (following the SimpleSignal design) moving the trigger method to the event object (which then passes itself by reference to each event responder). Without any changes to SMTK: a. Baseline: 131 +/- 7 nsec per setValue() call. With callback code added: b. No callbacks registered: 134 +/- 3 nsec per setValue() call. c. With 1000 empty callbacks: 2317 +/- 17 nsec per setValue() call. d. With 1 trivial callback: 142 +/- 7 nsec per setValue() call. Given that I've only instrumented 3 or 4 of the 61 different events so far, there is still plenty of work to do. However, this seems to be a reasonable design. The only issues left to address before working on the remaining events are 1. Should we investigate a signal-slot library? This seems redundant given the low overhead of the current design. 2. What is required to provide callback access to Python? Ben suggested writing a special callback that invokes a Python function (I'm guessing we would need one of these for each event type), but it's not clear to me how to integrate this with shiboken. David > On Aug 11, 2015, at 2:29 PM, David Thompson wrote: > > To follow up, > > 1. The timings in my original message were from a debug build (doh!). For a release build, the ratio of time spent is similar but the times are smaller (nanoseconds not microseconds): > > Without any changes to SMTK: > a. Baseline: 131 +/- 7 nsec per setValue() call. > With callback code added: > b. No callbacks registered: 340 +/- 6 nsec per setValue() call. > c. With 1000 empty callbacks: 2533 +/- 22 nsec per setValue() call. > d. With 1 trivial callback: 342 +/- 7 nsec per setValue() call. > > So, subtracting the apparent per-setValue cost (340 nsec) from the 1000-empty-callback version and dividing by 1000, it looks like 2.2 nsec per callback. > > 2. At least one signal-slot library I wanted to consider was SimpleSignal: > https://testbit.eu/cpp11-signal-system-performance/ > > David > > On Aug 11, 2015, at 11:38 AM, David Thompson wrote: > >> Hi all, >> >> I am working on adding callbacks to notify applications when attributes are changed. One of the concerns has been the overhead of callbacks on value change events, since these could conceivably happen frequently. I've done some preliminary benchmarking to quantify the cost of calling C++ lambdas each time an attribute value changes. The results are below. >> >> To benchmark the timing, I create an attribute with a single DoubleItem and repeatedly change the value of the DoubleItem to a random number. The timings were done on my MacBookPro running Mac OS X 10.9. >> >> Without any changes to SMTK: >> 1. Baseline: 0.355 +/- 0.01 usec per setValue() call. >> With callback code added: >> 2. No callbacks registered: 1.238 +/- 0.01 usec per setValue() call. >> 3. With 1000 empty callbacks: 21.32 +/- 0.20 usec per setValue() call. >> 4. With 1 trivial callback: 1.281 +/- 0.02 usec per setValue() call. >> >> These times were averaged over 5-6 runs, with each run consisting of 1-million setValue calls (except for the version with 1000 callbacks registered, which used 100,000 setValue calls per run). >> >> I have not evaluated signal/slot libraries; the callback code uses smtk::function to hold references to callbacks. >> >> David > From bob.obara at kitware.com Tue Aug 11 17:18:32 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 11 Aug 2015 17:18:32 -0400 Subject: [Smtk-developers] Attribute callback benchmarks In-Reply-To: <04E878BB-FAC5-4EA7-A713-2F19428A7A7F@kitware.com> References: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> <156C073D-A560-44A9-977D-F002B1242C2F@kitware.com> <04E878BB-FAC5-4EA7-A713-2F19428A7A7F@kitware.com> Message-ID: <1A0EF189-7D39-45D3-897B-718A04AD5469@kitware.com> If the test would take less then a day I would still do the test. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Aug 11, 2015, at 5:03 PM, David Thompson wrote: > > Hi all, > > In a continuing series of followups, I've been able to reduce the initial overhead of a callback to within a few nanoseconds of nothing by eliminating overhead from the construction of the event object and (following the SimpleSignal design) moving the trigger method to the event object (which then passes itself by reference to each event responder). > > Without any changes to SMTK: > a. Baseline: 131 +/- 7 nsec per setValue() call. > With callback code added: > b. No callbacks registered: 134 +/- 3 nsec per setValue() call. > c. With 1000 empty callbacks: 2317 +/- 17 nsec per setValue() call. > d. With 1 trivial callback: 142 +/- 7 nsec per setValue() call. > > Given that I've only instrumented 3 or 4 of the 61 different events so far, there is still plenty of work to do. However, this seems to be a reasonable design. > > The only issues left to address before working on the remaining events are > > 1. Should we investigate a signal-slot library? This seems redundant given the low overhead of the current design. > > 2. What is required to provide callback access to Python? Ben suggested writing a special callback that invokes a Python function (I'm guessing we would need one of these for each event type), but it's not clear to me how to integrate this with shiboken. > > David > >> On Aug 11, 2015, at 2:29 PM, David Thompson wrote: >> >> To follow up, >> >> 1. The timings in my original message were from a debug build (doh!). For a release build, the ratio of time spent is similar but the times are smaller (nanoseconds not microseconds): >> >> Without any changes to SMTK: >> a. Baseline: 131 +/- 7 nsec per setValue() call. >> With callback code added: >> b. No callbacks registered: 340 +/- 6 nsec per setValue() call. >> c. With 1000 empty callbacks: 2533 +/- 22 nsec per setValue() call. >> d. With 1 trivial callback: 342 +/- 7 nsec per setValue() call. >> >> So, subtracting the apparent per-setValue cost (340 nsec) from the 1000-empty-callback version and dividing by 1000, it looks like 2.2 nsec per callback. >> >> 2. At least one signal-slot library I wanted to consider was SimpleSignal: >> https://testbit.eu/cpp11-signal-system-performance/ >> >> David >> >> On Aug 11, 2015, at 11:38 AM, David Thompson wrote: >> >>> Hi all, >>> >>> I am working on adding callbacks to notify applications when attributes are changed. One of the concerns has been the overhead of callbacks on value change events, since these could conceivably happen frequently. I've done some preliminary benchmarking to quantify the cost of calling C++ lambdas each time an attribute value changes. The results are below. >>> >>> To benchmark the timing, I create an attribute with a single DoubleItem and repeatedly change the value of the DoubleItem to a random number. The timings were done on my MacBookPro running Mac OS X 10.9. >>> >>> Without any changes to SMTK: >>> 1. Baseline: 0.355 +/- 0.01 usec per setValue() call. >>> With callback code added: >>> 2. No callbacks registered: 1.238 +/- 0.01 usec per setValue() call. >>> 3. With 1000 empty callbacks: 21.32 +/- 0.20 usec per setValue() call. >>> 4. With 1 trivial callback: 1.281 +/- 0.02 usec per setValue() call. >>> >>> These times were averaged over 5-6 runs, with each run consisting of 1-million setValue calls (except for the version with 1000 callbacks registered, which used 100,000 setValue calls per run). >>> >>> I have not evaluated signal/slot libraries; the callback code uses smtk::function to hold references to callbacks. >>> >>> David >> > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Aug 17 14:40:00 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 17 Aug 2015 14:40:00 -0400 Subject: [Smtk-developers] Attribute callback benchmarks In-Reply-To: <04E878BB-FAC5-4EA7-A713-2F19428A7A7F@kitware.com> References: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> <156C073D-A560-44A9-977D-F002B1242C2F@kitware.com> <04E878BB-FAC5-4EA7-A713-2F19428A7A7F@kitware.com> Message-ID: <42C08B53-AC5A-4E41-8D6F-AA8AA3135EFB@kitware.com> Hi all, Not content with 2 followups, I have now simplified and adapted the callbacks to use the SimpleSignal header from (here)[https://testbit.eu/cpp11-signal-system-performance/]. Instead of callbacks like this: [](const ValueChangeEvent& event) { ... do stuff with event.item(), event.newValue(), ... } this version expects callbacks like [](Item* item, int index, const double& newValue) { ... do stuff with itm, newValue, ... } It is faster than anything else in the case where there are 0 or 1 observers, most probably because it does not construct an event object. It takes longer in the case of 1000 callbacks, most probably for the same reason. With few callbacks, the cost of constructing the event object is not amortized over enough invocations to make it worthwhile. But as more observers are added, the cost of calling each with multiple arguments containing all the callback info (thus requiring more pushes/pops to/from the stack) exceeds the cost of constructing the event: With TestBit's SimpleSignal callback code added: b. No callbacks registered: 34.3 +/- 0.5 nsec per setValue() call. c. With 1000 empty callbacks: 4124 +/- 49 nsec per setValue() call. d. With 1 trivial callback: 67.8 +/- 0.3 nsec per setValue() call. In any case, it would be wise to stick with event objects so that "high-level" callbacks can accept pointers to a base event object and cast to subclasses as required. However, I recommend using the SimpleSignal header as it provides some nice syntactic sugar and features like collectors (aggregating return values from multiple observers) and early termination based on observer return values. The test code for these benchmarks is in the attribute-callbacks-with-simplesignal of https://github.com/vibraphone/SMTK.git . https://github.com/vibraphone/smtk/commits/attribute-callbacks-with-simplesignal Please let me know if you have any comments. I have yet to play around with shiboken wrapping for observers (so that Python observers can be registered). If I can get that working, I plan to adapt the attribute-callbacks branch to use SimpleSignals whose observers take a single pointer to a callback event object. I'll also adapt the model-system callbacks to use SimpleSignal for consistency. David On Aug 11, 2015, at 5:03 PM, David Thompson wrote: > Hi all, > > In a continuing series of followups, I've been able to reduce the initial overhead of a callback to within a few nanoseconds of nothing by eliminating overhead from the construction of the event object and (following the SimpleSignal design) moving the trigger method to the event object (which then passes itself by reference to each event responder). > > Without any changes to SMTK: > a. Baseline: 131 +/- 7 nsec per setValue() call. > With callback code added: > b. No callbacks registered: 134 +/- 3 nsec per setValue() call. > c. With 1000 empty callbacks: 2317 +/- 17 nsec per setValue() call. > d. With 1 trivial callback: 142 +/- 7 nsec per setValue() call. > > Given that I've only instrumented 3 or 4 of the 61 different events so far, there is still plenty of work to do. However, this seems to be a reasonable design. > > The only issues left to address before working on the remaining events are > > 1. Should we investigate a signal-slot library? This seems redundant given the low overhead of the current design. > > 2. What is required to provide callback access to Python? Ben suggested writing a special callback that invokes a Python function (I'm guessing we would need one of these for each event type), but it's not clear to me how to integrate this with shiboken. > > David > >> On Aug 11, 2015, at 2:29 PM, David Thompson wrote: >> >> To follow up, >> >> 1. The timings in my original message were from a debug build (doh!). For a release build, the ratio of time spent is similar but the times are smaller (nanoseconds not microseconds): >> >> Without any changes to SMTK: >> a. Baseline: 131 +/- 7 nsec per setValue() call. >> With callback code added: >> b. No callbacks registered: 340 +/- 6 nsec per setValue() call. >> c. With 1000 empty callbacks: 2533 +/- 22 nsec per setValue() call. >> d. With 1 trivial callback: 342 +/- 7 nsec per setValue() call. >> >> So, subtracting the apparent per-setValue cost (340 nsec) from the 1000-empty-callback version and dividing by 1000, it looks like 2.2 nsec per callback. >> >> 2. At least one signal-slot library I wanted to consider was SimpleSignal: >> https://testbit.eu/cpp11-signal-system-performance/ >> >> David >> >> On Aug 11, 2015, at 11:38 AM, David Thompson wrote: >> >>> Hi all, >>> >>> I am working on adding callbacks to notify applications when attributes are changed. One of the concerns has been the overhead of callbacks on value change events, since these could conceivably happen frequently. I've done some preliminary benchmarking to quantify the cost of calling C++ lambdas each time an attribute value changes. The results are below. >>> >>> To benchmark the timing, I create an attribute with a single DoubleItem and repeatedly change the value of the DoubleItem to a random number. The timings were done on my MacBookPro running Mac OS X 10.9. >>> >>> Without any changes to SMTK: >>> 1. Baseline: 0.355 +/- 0.01 usec per setValue() call. >>> With callback code added: >>> 2. No callbacks registered: 1.238 +/- 0.01 usec per setValue() call. >>> 3. With 1000 empty callbacks: 21.32 +/- 0.20 usec per setValue() call. >>> 4. With 1 trivial callback: 1.281 +/- 0.02 usec per setValue() call. >>> >>> These times were averaged over 5-6 runs, with each run consisting of 1-million setValue calls (except for the version with 1000 callbacks registered, which used 100,000 setValue calls per run). >>> >>> I have not evaluated signal/slot libraries; the callback code uses smtk::function to hold references to callbacks. >>> >>> David >> > From david.thompson at kitware.com Tue Aug 18 19:01:28 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 18 Aug 2015 19:01:28 -0400 Subject: [Smtk-developers] Attribute callback benchmarks In-Reply-To: <42C08B53-AC5A-4E41-8D6F-AA8AA3135EFB@kitware.com> References: <150A8A18-3871-4FEA-9AE2-3B7F9DFA747C@kitware.com> <156C073D-A560-44A9-977D-F002B1242C2F@kitware.com> <04E878BB-FAC5-4EA7-A713-2F19428A7A7F@kitware.com> <42C08B53-AC5A-4E41-8D6F-AA8AA3135EFB@kitware.com> Message-ID: Hi all, For today's followup, I've got... more exciting timings! This go-round uses the TestBit.eu simple::Signal object to track observers for each signal. Observers are called with a pointer to an smtk::attribute::EventData subclass. b. No callbacks registered: 41 ns/call c. With 1000 empty callbacks: 3854 ns/call d. With 1 trivial callback: 46 ns/call e. 1000 per-instance callbacks: 5203 ns/call Note that there is a new time: per-instance callback (e). By specific request, I am now testing how expensive it is to use the static (per class) signal objects to invoke callbacks when an event occurs on just a single instance instead of on all instances of an Item. This also adds some syntactic sugar to make registering a callback on a single instance simple: // This will be called every time *any* double-item value changes: ItemValueChangedEvent::responses() += [](const ItemValueValueChangeEvent*) { std::cout << "Message A: Something changed.\n"; }; // Now register a callback for one specific double-item: DoubleItem* itm = attribute1->findDouble("stuff"); itm->connect( [attribute1](const ItemValueChangeEvent*) { std::cout << "Message B: Stuff changed on attribute " << attribute1->name() << "\n"; }); itm->setValue(0, 3.1415); // Prints message A and B. itm = attribute2->findDouble("stuff"); itm->setValue(0, 2.71828); // Prints only message A. Timing (e) above creates a single attribute definition that owns 1000 items. Then, each item is given its own per-instance callback (like message B above, except that it just increments a counter instead of printing a message). Each of the 1000 items then has its value changed 1000 times (for a total of 1 million setValue calls and 1 billion callback invocations). While registering per-instance callbacks adds a per-event cost, it is not terribly expensive and it does save us from having to store a list of observers per-instance+per-event. Which would be unsanity. The new code is now up on the attribute-callbacks branch of https://github.com/vibraphone/SMTK.git . At some point soon, I'll write a little bit more about how we can trigger high-level events when each low-level event occurs. David On Aug 17, 2015, at 2:40 PM, David Thompson wrote: > Hi all, > > Not content with 2 followups, I have now simplified and adapted the callbacks to use the SimpleSignal header from (here)[https://testbit.eu/cpp11-signal-system-performance/]. > > Instead of callbacks like this: > > [](const ValueChangeEvent& event) { ... do stuff with event.item(), event.newValue(), ... } > > this version expects callbacks like > > [](Item* item, int index, const double& newValue) { ... do stuff with itm, newValue, ... } > > It is faster than anything else in the case where there are 0 or 1 observers, most probably because it does not construct an event object. It takes longer in the case of 1000 callbacks, most probably for the same reason. With few callbacks, the cost of constructing the event object is not amortized over enough invocations to make it worthwhile. But as more observers are added, the cost of calling each with multiple arguments containing all the callback info (thus requiring more pushes/pops to/from the stack) exceeds the cost of constructing the event: > > > With TestBit's SimpleSignal callback code added: > b. No callbacks registered: 34.3 +/- 0.5 nsec per setValue() call. > c. With 1000 empty callbacks: 4124 +/- 49 nsec per setValue() call. > d. With 1 trivial callback: 67.8 +/- 0.3 nsec per setValue() call. > > In any case, it would be wise to stick with event objects so that "high-level" callbacks can accept pointers to a base event object and cast to subclasses as required. > > However, I recommend using the SimpleSignal header as it provides some nice syntactic sugar and features like collectors (aggregating return values from multiple observers) and early termination based on observer return values. > > The test code for these benchmarks is in the attribute-callbacks-with-simplesignal of https://github.com/vibraphone/SMTK.git . > > https://github.com/vibraphone/smtk/commits/attribute-callbacks-with-simplesignal > > Please let me know if you have any comments. > > I have yet to play around with shiboken wrapping for observers (so that Python observers can be registered). If I can get that working, I plan to adapt the attribute-callbacks branch to use SimpleSignals whose observers take a single pointer to a callback event object. I'll also adapt the model-system callbacks to use SimpleSignal for consistency. > > David > > On Aug 11, 2015, at 5:03 PM, David Thompson wrote: > >> Hi all, >> >> In a continuing series of followups, I've been able to reduce the initial overhead of a callback to within a few nanoseconds of nothing by eliminating overhead from the construction of the event object and (following the SimpleSignal design) moving the trigger method to the event object (which then passes itself by reference to each event responder). >> >> Without any changes to SMTK: >> a. Baseline: 131 +/- 7 nsec per setValue() call. >> With callback code added: >> b. No callbacks registered: 134 +/- 3 nsec per setValue() call. >> c. With 1000 empty callbacks: 2317 +/- 17 nsec per setValue() call. >> d. With 1 trivial callback: 142 +/- 7 nsec per setValue() call. >> >> Given that I've only instrumented 3 or 4 of the 61 different events so far, there is still plenty of work to do. However, this seems to be a reasonable design. >> >> The only issues left to address before working on the remaining events are >> >> 1. Should we investigate a signal-slot library? This seems redundant given the low overhead of the current design. >> >> 2. What is required to provide callback access to Python? Ben suggested writing a special callback that invokes a Python function (I'm guessing we would need one of these for each event type), but it's not clear to me how to integrate this with shiboken. >> >> David >> >>> On Aug 11, 2015, at 2:29 PM, David Thompson wrote: >>> >>> To follow up, >>> >>> 1. The timings in my original message were from a debug build (doh!). For a release build, the ratio of time spent is similar but the times are smaller (nanoseconds not microseconds): >>> >>> Without any changes to SMTK: >>> a. Baseline: 131 +/- 7 nsec per setValue() call. >>> With callback code added: >>> b. No callbacks registered: 340 +/- 6 nsec per setValue() call. >>> c. With 1000 empty callbacks: 2533 +/- 22 nsec per setValue() call. >>> d. With 1 trivial callback: 342 +/- 7 nsec per setValue() call. >>> >>> So, subtracting the apparent per-setValue cost (340 nsec) from the 1000-empty-callback version and dividing by 1000, it looks like 2.2 nsec per callback. >>> >>> 2. At least one signal-slot library I wanted to consider was SimpleSignal: >>> https://testbit.eu/cpp11-signal-system-performance/ >>> >>> David >>> >>> On Aug 11, 2015, at 11:38 AM, David Thompson wrote: >>> >>>> Hi all, >>>> >>>> I am working on adding callbacks to notify applications when attributes are changed. One of the concerns has been the overhead of callbacks on value change events, since these could conceivably happen frequently. I've done some preliminary benchmarking to quantify the cost of calling C++ lambdas each time an attribute value changes. The results are below. >>>> >>>> To benchmark the timing, I create an attribute with a single DoubleItem and repeatedly change the value of the DoubleItem to a random number. The timings were done on my MacBookPro running Mac OS X 10.9. >>>> >>>> Without any changes to SMTK: >>>> 1. Baseline: 0.355 +/- 0.01 usec per setValue() call. >>>> With callback code added: >>>> 2. No callbacks registered: 1.238 +/- 0.01 usec per setValue() call. >>>> 3. With 1000 empty callbacks: 21.32 +/- 0.20 usec per setValue() call. >>>> 4. With 1 trivial callback: 1.281 +/- 0.02 usec per setValue() call. >>>> >>>> These times were averaged over 5-6 runs, with each run consisting of 1-million setValue calls (except for the version with 1000 callbacks registered, which used 100,000 setValue calls per run). >>>> >>>> I have not evaluated signal/slot libraries; the callback code uses smtk::function to hold references to callbacks. >>>> >>>> David >>> >> > From bob.obara at kitware.com Thu Aug 27 12:52:33 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 27 Aug 2015 12:52:33 -0400 Subject: [Smtk-developers] Warnings Message-ID: <5F9E016A-09F4-4278-B96F-0E09DC7D5091@kitware.com> Hi Folks, When I build SMTK I?m seeing a lot of warnings - some of which are going from things like VTK. Bob /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkType.h:225:16: warning: 'long long' is a C++11 extension [-Wc++11-long-long] typedef signed long long vtkTypeInt64; ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkType.h:268:9: warning: 'long long' is a C++11 extension [-Wc++11-long-long] typedef long long vtkIdType; ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:21: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkMultiBlockDataSet.h:40: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObjectTree.h:34: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkCompositeDataSet.h:34: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObject.h:36: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkObject.h:42: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkObjectBase.h:44: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkIndent.h:25: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkSystemIncludes.h:46: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkOStreamWrapper.h:82:35: warning: 'long long' is a C++11 extension [-Wc++11-long-long] vtkOStreamWrapper& operator << (long long); ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkOStreamWrapper.h:83:44: warning: 'long long' is a C++11 extension [-Wc++11-long-long] vtkOStreamWrapper& operator << (unsigned long long); ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/discrete/smtkDiscreteSessionPython/smtk_shared_ptr_smtk_bridge_discrete_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/discrete/smtkDiscreteSessionPython/smtkdiscretesessionpython_python.h:14: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/smtkCorePython/smtkcorepython_python.h:112: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/thirdparty/sparsehash/sparse_hash_map:93: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/thirdparty/sparsehash/internal/sparsehashtable.h:106: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/thirdparty/sparsehash/sparsetable:1653:18: warning: 'long long' is a C++11 extension [-Wc++11-long-long] if ( value < 0xFFFFFFFFULL ) { // fits in 4 bytes ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/thirdparty/sparsehash/sparsetable:1670:19: warning: 'long long' is a C++11 extension [-Wc++11-long-long] if ( first4 < 0xFFFFFFFFULL ) { ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:21: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkMultiBlockDataSet.h:40: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObjectTree.h:34: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkCompositeDataSet.h:34: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObject.h:36: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkObject.h:53:40: warning: extra ';' inside a class [-Wextra-semi] vtkTypeMacro(vtkObject,vtkObjectBase); ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:21: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkMultiBlockDataSet.h:40: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObjectTree.h:34: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkCompositeDataSet.h:34: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObject.h:61:40: warning: extra ';' inside a class [-Wextra-semi] vtkTypeMacro(vtkDataObject,vtkObject); ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:21: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkMultiBlockDataSet.h:40: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObjectTree.h:34: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkCompositeDataSet.h:45:51: warning: extra ';' inside a class [-Wextra-semi] vtkTypeMacro(vtkCompositeDataSet, vtkDataObject); ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:21: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkMultiBlockDataSet.h:40: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkDataObjectTree.h:46:55: warning: extra ';' inside a class [-Wextra-semi] vtkTypeMacro(vtkDataObjectTree, vtkCompositeDataSet); ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:21: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/DataModel/vtkMultiBlockDataSet.h:46:56: warning: extra ';' inside a class [-Wextra-semi] vtkTypeMacro(vtkMultiBlockDataSet, vtkDataObjectTree); ^ In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtk_shared_ptr_smtk_bridge_exodus_session__wrapper.cpp:6: In file included from /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk-build/smtk/bridge/exodus/smtkExodusSessionPython/smtkexodussessionpython_python.h:17: /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/bridge/exodus/Session.h:92:3: warning: extra ';' inside a class [-Wextra-semi] smtkDeclareModelingKernel(); ^ /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/model/Session.h:200:36: note: expanded from macro 'smtkDeclareModelingKernel' smtkDeclareOperatorRegistration(); ^ 1310 warnings generated. Linking CXX shared module ../../../lib/smtkRemoteSessionPython.so [100%] Built target smtkRemoteSessionPython 207 warnings generated. Linking CXX shared module ../../../lib/smtkExodusSessionPython.so 202 warnings generated. Linking CXX shared module ../../../lib/smtkDiscreteSessionPython.so [100%] Built target smtkExodusSessionPython [100%] Built target smtkDiscreteSessionPython Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Aug 27 17:13:04 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 27 Aug 2015 17:13:04 -0400 Subject: [Smtk-developers] Warnings In-Reply-To: <5F9E016A-09F4-4278-B96F-0E09DC7D5091@kitware.com> Message-ID: <20150827211304.GA14772@megas.kitware.com> On Thu, Aug 27, 2015 at 12:52:33 -0400, Robert Michael O'Bara wrote: > /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/model/Session.h:200:36: note: > expanded from macro 'smtkDeclareModelingKernel' > smtkDeclareOperatorRegistration(); > ^ These would need a style change to SMTK. > /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkType.h:225:16: warning: > 'long long' is a C++11 extension [-Wc++11-long-long] > typedef signed long long vtkTypeInt64; ... > 1310 warnings generated. > Linking CXX shared module ../../../lib/smtkRemoteSessionPython.so SMTK is setting -std=c++11, but VTK headers are not warning-clean in such a situation. SMTK should either use "SYSTEM" as the first argument when adding VTK/ParaView include directories or not set C++11 as its target. --Ben From david.thompson at kitware.com Thu Aug 27 17:15:04 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 27 Aug 2015 17:15:04 -0400 Subject: [Smtk-developers] Warnings In-Reply-To: <20150827211304.GA14772@megas.kitware.com> References: <20150827211304.GA14772@megas.kitware.com> Message-ID: <4D569ED6-31ED-403F-A9F7-DB5BC58E56E0@kitware.com> We could also use pragmas around VTK includes to turn off C++11 warnings. We do something similar for other 3rd party libraries. David > On Aug 27, 2015, at 5:13 PM, Ben Boeckel wrote: > > On Thu, Aug 27, 2015 at 12:52:33 -0400, Robert Michael O'Bara wrote: >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/model/Session.h:200:36: note: >> expanded from macro 'smtkDeclareModelingKernel' >> smtkDeclareOperatorRegistration(); >> ^ > > These would need a style change to SMTK. > >> /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkType.h:225:16: warning: >> 'long long' is a C++11 extension [-Wc++11-long-long] >> typedef signed long long vtkTypeInt64; > > ... > >> 1310 warnings generated. >> Linking CXX shared module ../../../lib/smtkRemoteSessionPython.so > > SMTK is setting -std=c++11, but VTK headers are not warning-clean in such a > situation. SMTK should either use "SYSTEM" as the first argument when adding > VTK/ParaView include directories or not set C++11 as its target. > > --Ben > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From bob.obara at kitware.com Thu Aug 27 17:32:21 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 27 Aug 2015 17:32:21 -0400 Subject: [Smtk-developers] Warnings In-Reply-To: <4D569ED6-31ED-403F-A9F7-DB5BC58E56E0@kitware.com> References: <20150827211304.GA14772@megas.kitware.com> <4D569ED6-31ED-403F-A9F7-DB5BC58E56E0@kitware.com> Message-ID: <91DC1747-2140-4911-8BB4-334B4F6B1B25@kitware.com> I'm ok with either approach. Bob Sent from my iPad > On Aug 27, 2015, at 5:15 PM, David Thompson wrote: > > We could also use pragmas around VTK includes to turn off C++11 warnings. We do something similar for other 3rd party libraries. > > David > >> On Aug 27, 2015, at 5:13 PM, Ben Boeckel wrote: >> >> On Thu, Aug 27, 2015 at 12:52:33 -0400, Robert Michael O'Bara wrote: >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/model/Session.h:200:36: note: >>> expanded from macro 'smtkDeclareModelingKernel' >>> smtkDeclareOperatorRegistration(); >>> ^ >> >> These would need a style change to SMTK. >> >>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkType.h:225:16: warning: >>> 'long long' is a C++11 extension [-Wc++11-long-long] >>> typedef signed long long vtkTypeInt64; >> >> ... >> >>> 1310 warnings generated. >>> Linking CXX shared module ../../../lib/smtkRemoteSessionPython.so >> >> SMTK is setting -std=c++11, but VTK headers are not warning-clean in such a >> situation. SMTK should either use "SYSTEM" as the first argument when adding >> VTK/ParaView include directories or not set C++11 as its target. >> >> --Ben >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > From david.thompson at kitware.com Thu Aug 27 17:44:12 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 27 Aug 2015 17:44:12 -0400 Subject: [Smtk-developers] Warnings In-Reply-To: <91DC1747-2140-4911-8BB4-334B4F6B1B25@kitware.com> References: <20150827211304.GA14772@megas.kitware.com> <4D569ED6-31ED-403F-A9F7-DB5BC58E56E0@kitware.com> <91DC1747-2140-4911-8BB4-334B4F6B1B25@kitware.com> Message-ID: <582E3D40-D472-4D42-991A-E691A9854B82@kitware.com> Ben, how would SYSTEM work with VTK? IIRC, VTK either uses the new transitive include directories or hides the INCLUDE_DIRECTORIES command inside ${VTK_USE_FILE}, which would make adding SYSTEM tricky. David > I'm ok with either approach. > Bob > > Sent from my iPad > >> On Aug 27, 2015, at 5:15 PM, David Thompson wrote: >> >> We could also use pragmas around VTK includes to turn off C++11 warnings. We do something similar for other 3rd party libraries. >> >> David >> >>> On Aug 27, 2015, at 5:13 PM, Ben Boeckel wrote: >>> >>> On Thu, Aug 27, 2015 at 12:52:33 -0400, Robert Michael O'Bara wrote: >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/smtk/src/smtk/smtk/model/Session.h:200:36: note: >>>> expanded from macro 'smtkDeclareModelingKernel' >>>> smtkDeclareOperatorRegistration(); >>>> ^ >>> >>> These would need a style change to SMTK. >>> >>>> /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/paraview/src/paraview/VTK/Common/Core/vtkType.h:225:16: warning: >>>> 'long long' is a C++11 extension [-Wc++11-long-long] >>>> typedef signed long long vtkTypeInt64; >>> >>> ... >>> >>>> 1310 warnings generated. >>>> Linking CXX shared module ../../../lib/smtkRemoteSessionPython.so >>> >>> SMTK is setting -std=c++11, but VTK headers are not warning-clean in such a >>> situation. SMTK should either use "SYSTEM" as the first argument when adding >>> VTK/ParaView include directories or not set C++11 as its target. >>> >>> --Ben >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> http://public.kitware.com/mailman/listinfo/smtk-developers >> From ben.boeckel at kitware.com Thu Aug 27 18:11:28 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 27 Aug 2015 18:11:28 -0400 Subject: [Smtk-developers] Warnings In-Reply-To: <582E3D40-D472-4D42-991A-E691A9854B82@kitware.com> References: <20150827211304.GA14772@megas.kitware.com> <4D569ED6-31ED-403F-A9F7-DB5BC58E56E0@kitware.com> <91DC1747-2140-4911-8BB4-334B4F6B1B25@kitware.com> <582E3D40-D472-4D42-991A-E691A9854B82@kitware.com> Message-ID: <20150827221128.GA16277@megas.kitware.com> On Thu, Aug 27, 2015 at 17:44:12 -0400, David Thompson wrote: > Ben, how would SYSTEM work with VTK? IIRC, VTK either uses the new > transitive include directories Hmm. Not sure. > or hides the INCLUDE_DIRECTORIES > command inside ${VTK_USE_FILE}, which would make adding SYSTEM tricky. Ew. That file should use SYSTEM if it does include_directories there. --Ben