GRC Reacting Slowly

GNU Radio
#1

GNU Radio 3.7.8, Ubuntu 14.04

I have an admittedly large number of blocks in my current flow graph
because I’m in the middle of some hardcore debugging. Every time I
select a
block to enable/disable it, there is a > 2 second delay between the
block
becoming enabled/disabled and hitting the E/D keys. The same is true
when
connecting new ports together with wires. I’ve been working with this
for a
while, but it’s annoying enough now that I’d like to know if there is a
workaround to this or simply understand the cause of it?

v/r,
Rich

#2

Hi rich,

on which hardware platform are you working ? Is this a PC or embedded
device ?

cheers,
Andy

Am 27.05.2015 um 01:09 schrieb Richard B.:

#3

I had this problem for a while when using a large number of blocks. The
cause, I think, is that the companion checks if the flowgraph is correct
after every change. You will only be able to compile if it’s correct
(blocks are connected, variable names exist…).
If this is really the reason, It would be nice to have an icon that,
when
unselected disables this check and when selected it checks the flowgraph
and enables the compile and run options if everything is ok.

Regards,
Murray

2015-05-27 16:08 GMT+01:00 Andreas L. [email protected]:

#4

Hi Richard,

I’ll pitch perf here (you’re on Ubuntu, so it’s in the linux-tools,
probably).
Build GNU Radio with the debugging symbols enabled, i.e. call CMake with
the build type specified:

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo …

Then, allow normal users to sniff around processes’ calls:

sudo sysctl kernel/perf_event_paranoid=-1

Run GRC to see where time is spent (-a is for “all CPUs”)

perf record -a gnuradio-companion

play around in GRC. Close it and interpret the result as shown by

perf report

Greetings,
Marcus

#5

On Thu, May 28, 2015 at 12:05 AM, Marcus Müller
[email protected]
wrote:

I’ll pitch perf here (you’re on Ubuntu, so it’s in the linux-tools,
probably).

I’m pretty sure the issue is as Murray T. described above. We’ve
had
to optimize this area in the past in GRC.

#6

Andreas,

No I’m not using an embedded system to develop on. I’m using an HP Core
i7
laptop with 16Gig of RAM, Ubuntu 14.04 with GNU Radio 3.7.8.

The delay also occurs everytime I want to make a change to a blocks
paramters. I have to wait >2 seconds for the blocks paramter window to
open
and then another >2 seconds for it to close. It all adds up. If the
reason
is what Murray said, I would agree it would be nice to have the option
of
checking only when you click the play button or something similar.

v/r,
Rich

On Wed, May 27, 2015 at 12:08 PM, Murray T.
<[email protected]

#7

Hi Murray,

thats an interesting fact.

My project has a lot (i didnt count them) of blocks. I have the same
delay problem on my PC and on my embedded device. On the embedded
device its slower than on my pc :slight_smile:

If i use only a few blocks than the delay is short.

So i think your theory and suggestion is great.

Andy

Am 27.05.2015 um 21:08 schrieb Murray T.:

#8

Hey,

so, I timed the flowgrah update steps rewrite, validate, create labels,
create shapes and it turns out most time is actually spent in validate.
However, for some reason the validate step currently performs the
evaluation of the params and this is also where it spends almost all of
its time. So, moving this to rewrite and making validate optional is
certainly possible, but doesn’t help (because then validate takes no
time to run). Further profiling is required.

Sebastian