[PATCH] runqueue.py: always emit bb.event.DepTreeGenerated

[PATCH] runqueue.py: always emit bb.event.DepTreeGenerated

[Patrick Ohly]

The data included in the event is useful for implementing a pre-build
check that warns about unexpected components, for example because of
an incorrect configuration or changed dependencies.

Such a check can be done in a .bbclass that gets inherited
globally. But in contrast to a UI, such a class cannot request that
the event shall be emitted, and thus the event has to be emitted
whether there is a consumer or not.

This was done conditionally earlier out of concerns about the
performance impact. But now events are handled more efficiently, so
that concern no longer seems valid: in some simple testing (admittedly
on a fast build workstation), the two lines (generating the data and
emitting the event with it) only took about 0.05 seconds (measured
with timeit). That was for a build with roughly 500 recipes (from
pn-buildlist aka depgraph['pn']), triggered via the command line. That
was even with a consumer of the data active and doing some work, so it
should be even faster when there is no consumer.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 lib/bb/runqueue.py | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/bb/runqueue.py b/lib/bb/runqueue.py
index 8b3fe5a..2d4893d 100644
--- a/lib/bb/runqueue.py
+++ b/lib/bb/runqueue.py
@@ -1122,10 +1122,10 @@ class RunQueue:
             else:
                 self.state = runQueueSceneInit
 
-                # we are ready to run, see if any UI client needs the dependency info
-                if bb.cooker.CookerFeatures.SEND_DEPENDS_TREE in self.cooker.featureset:
-                    depgraph = self.cooker.buildDependTree(self, self.rqdata.taskData)
-                    bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.cooker.data)
+                # we are ready to run,  emit dependency info to any UI or class which
+                # needs it
+                depgraph = self.cooker.buildDependTree(self, self.rqdata.taskData)
+                bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.cooker.data)
 
         if self.state is runQueueSceneInit:
             dump = self.cooker.configuration.dump_signatures
-- 
2.1.4

Re: [PATCH] runqueue.py: always emit bb.event.DepTreeGenerated

[Richard Purdie]

On Thu, 2016-05-12 at 17:00 +0200, Patrick Ohly wrote:
> The data included in the event is useful for implementing a pre-build
> check that warns about unexpected components, for example because of
> an incorrect configuration or changed dependencies.
> 
> Such a check can be done in a .bbclass that gets inherited
> globally. But in contrast to a UI, such a class cannot request that
> the event shall be emitted, and thus the event has to be emitted
> whether there is a consumer or not.
> 
> This was done conditionally earlier out of concerns about the
> performance impact. But now events are handled more efficiently, so
> that concern no longer seems valid: in some simple testing
> (admittedly
> on a fast build workstation), the two lines (generating the data and
> emitting the event with it) only took about 0.05 seconds (measured
> with timeit). That was for a build with roughly 500 recipes (from
> pn-buildlist aka depgraph['pn']), triggered via the command line.
> That
> was even with a consumer of the data active and doing some work, so
> it
> should be even faster when there is no consumer.

I've taken this since now we have event filtering, we don't take the
IPC/RPC cost for data that the receiver doesn't care about. I added a
follow up patch which removes the feature entirely since this code
block was the only reason for it.

Cheers,

Richard

[PATCH] runqueue.py: always emit bb.event.DepTreeGenerated

[Patrick Ohly]

The data included in the event is useful for implementing a pre-build
check that warns about unexpected components, for example because of
an incorrect configuration or changed dependencies.

Such a check can be done in a .bbclass that gets inherited
globally. But in contrast to a UI, such a class cannot request that
the event shall be emitted, and thus the event has to be emitted
whether there is a consumer or not.

This was done conditionally earlier out of concerns about the
performance impact. But now events are handled more efficiently, so
that concern no longer seems valid: in some simple testing (admittedly
on a fast build workstation), the two lines (generating the data and
emitting the event with it) only took about 0.05 seconds (measured
with timeit). That was for a build with roughly 500 recipes (from
pn-buildlist aka depgraph['pn']), triggered via the command line. That
was even with a consumer of the data active and doing some work, so it
should be even faster when there is no consumer.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 lib/bb/runqueue.py | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/bb/runqueue.py b/lib/bb/runqueue.py
index 8b3fe5a..2d4893d 100644
--- a/lib/bb/runqueue.py
+++ b/lib/bb/runqueue.py
@@ -1122,10 +1122,10 @@ class RunQueue:
             else:
                 self.state = runQueueSceneInit
 
-                # we are ready to run, see if any UI client needs the dependency info
-                if bb.cooker.CookerFeatures.SEND_DEPENDS_TREE in self.cooker.featureset:
-                    depgraph = self.cooker.buildDependTree(self, self.rqdata.taskData)
-                    bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.cooker.data)
+                # we are ready to run,  emit dependency info to any UI or class which
+                # needs it
+                depgraph = self.cooker.buildDependTree(self, self.rqdata.taskData)
+                bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.cooker.data)
 
         if self.state is runQueueSceneInit:
             dump = self.cooker.configuration.dump_signatures
-- 
2.1.4