[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Completely blank flowgraph takes a minute to generate
From: |
Marcus Müller |
Subject: |
Re: Completely blank flowgraph takes a minute to generate |
Date: |
Mon, 4 Oct 2021 12:06:52 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
Hi Jameson,
don't overdo it! Johannes' approach might really be the more sensible here!
On 03.10.21 22:06, Jameson Collins wrote:
> So I haven't forgotten about this, it's just turned into more work than
> expected. The
> target didn't have perf, and it turns out there was a kernel bug that made it
> unusable.
> Fixed that, and then didn't have enough space on the ram filesystem anymore.
> Fixed that
> and noticed that I don't get function names, just addresses. Currently
> working on that
> problem.
>
> On Wed, Sep 29, 2021 at 1:26 PM Marcus Müller <mueller@kit.edu
> <mailto:mueller@kit.edu>>
> wrote:
>
> Hi Jameson,
>
> yep, and if it's not IO-bound, it's still a lot of YAML files to parse,
> so it's really a nice mini-benchmark for your filesystem and python's
> yaml implementation. By the way, which version of GNU Radio are you
> running?
> If you want to have a look into what your OS is up to while you run
> grcc, I'd run `sudo perf record -a -g grcc parameters...`
>
> followed by `perf report`; it's not as useful to profile the Python side
> of things, Johannes' method is the right one here, but in case you need
> to know in which libc function or which kernel function you're stuck
> most of the time: great tool!
>
> Best regards,
> Marcus
>
> On 29/09/2021 14.04, Jameson Collins wrote:
> > @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>
> > <mailto: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>
> > <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?
> > >
> >
>
smime.p7s
Description: S/MIME Cryptographic Signature