@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 <mmuel...@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 > > 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? > > > >
