@Johannes, that's neat. I'll give that a shot.
@Marcus, I can't run GRC on the target as it doesn't have X. I'm using
grcc to generate the block, I should have mentioned that. When you say
IO-bound I'm guessing you mean because it's scanning the disk? I
haven't benchmarked this hardware yet, but the filesystem is a ram disk
so I would expect it to be reasonably fast. But this is something I can
look into.
Thanks
On Wed, Sep 29, 2021 at 6:55 AM Marcus Müller <mmueller@gnuradio.org
<mailto:mmueller@gnuradio.org>> wrote:
But before going into too much depth, make sure the duration isn't just
basically identical to clicking on the "reload block library" button,
which is first IO-bound (which *can* take significant amount of CPU
time
on weaker ARMs) and then parsing-limited.
Best Regards,
Marcus
On 9/29/21 11:21 AM, Johannes Demel wrote:
> Hi,
>
> I used:
> https://docs.python.org/3/library/profile.html#module-cProfile
<https://docs.python.org/3/library/profile.html#module-cProfile>
> in the past to locate the problematic lines of code.
>
> ```
> import cProfile
> import pstats
>
> with cProfile.Profile() as pr:
> run_the_problematic_function_etc()
> stats = pstats.Stats(pr)
> stats.sort_stats('cumtime').reverse_order()
> stats.print_stats()
> ```
> You might want to adopt these lines for your use-case. I started at
> the top-level of my application and then gradually moved the code
to a
> more fitting function.
>
> Cheers
> Johannes
>
> On 28.09.21 23:40, Jameson Collins wrote:
>> I have a completely blank flowgraph (well just the default
'Options'
>> block).
>>
>> On my 8 core, 2 GHz, Intel based virtual machine this flowgraph
>> generates in under a second.
>>
>> On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and
>> completely maxes out 1 core while it's running.
>>
>> Why might cause this? How might I troubleshoot it?
>