Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

applying a filter in huge recordings take very long (QWidget::changeEvent() calling qHash) #534

Closed
GitMensch opened this issue Oct 19, 2023 · 7 comments
Labels
bug needs_info not enough info

Comments

@GitMensch
Copy link
Contributor

Describe the bug
Applying a filter in huge recordings take very long. Maybe this can this be improved?

To Reproduce
Open a huge recording, then wait until it is opened, then apply a exclusion filter for a symbol - wait very long.

Expected behavior
Not taking several minutes for a filter to apply.

Additional context
I've recorded this long standing filtering from a separate hotspot instance (profiling for some seconds, then stopped), then opened that recording with hotspot.
Here are the results (recursive QWidget::changeEvent() calling qHash(QString) with ):
flamegraph
caller/callee

If useful, then I can upload the inspected perf.data.hotspot-filter (38,435,235 Bytes), taken from appimage, analyzed with appPath and debugPath set.

@GitMensch GitMensch added the bug label Oct 19, 2023
@milianw
Copy link
Member

milianw commented Oct 20, 2023

the backtrace looks pretty broken to me, why would QWidget::changeEvent do a qHash lookup? are you really sure that the debug information matches the build used in the appimage?

@milianw
Copy link
Member

milianw commented Oct 20, 2023

yeah, just double checked, and this is not it - I suspect the wrong Qt5Core debug information is used for some reason?

void QWidget::changeEvent(QEvent * event)
{
    switch(event->type()) {
    case QEvent::EnabledChange: {
        update();
#ifndef QT_NO_ACCESSIBILITY
        QAccessible::State s;
        s.disabled = true;
        QAccessibleStateChangeEvent event(this, s);
        QAccessible::updateAccessibility(&event);
#endif
        break;
    }

    case QEvent::FontChange:
    case QEvent::StyleChange: {
        Q_D(QWidget);
        update();
        updateGeometry();
        if (d->layout)
            d->layout->invalidate();
        break;
    }

    case QEvent::PaletteChange:
        update();
        break;

    case QEvent::ThemeChange:
        if (QGuiApplication::desktopSettingsAware() && windowType() != Qt::Desktop
            && qApp && !QCoreApplication::closingDown()) {
            if (testAttribute(Qt::WA_WState_Polished))
                QApplication::style()->unpolish(this);
            if (testAttribute(Qt::WA_WState_Polished))
                QApplication::style()->polish(this);
            QEvent styleChangedEvent(QEvent::StyleChange);
            QCoreApplication::sendEvent(this, &styleChangedEvent);
            if (isVisible())
                update();
        }
        break;

#ifdef Q_OS_MAC
    case QEvent::MacSizeChange:
        updateGeometry();
        break;
#endif

    default:
        break;
    }
}

@GitMensch
Copy link
Contributor Author

why would QWidget::changeEvent do a qHash lookup?

I don't know.

this is not it - I suspect the wrong Qt5Core debug information is used for some reason?

It was recorded by the appimage and the debuginfo is from the same build.

But I do recognize "strange" stacks shown in perf traces.
I assume that this is because of missing debuginfo (that was also shown in this recording of hotspot), there are commonly only view missing entries but as you see on the right - there is no location shown - are you sure that there's enough debuginfo for the appimage available? Checking that sounds like a separate issue though.

For this very issue: can you reproduce this by recording some long cpu-intense process, then open the trace with hotspot and apply a filter?

@milianw
Copy link
Member

milianw commented Oct 21, 2023

it takes time, but filtering is done in the background thread and it doesn't take minutes either for me. can you export a perfparser file from hotspot and make it available for me and then tell me what you are filtering on that makes it so slow?

@milianw
Copy link
Member

milianw commented Nov 11, 2023

ping?

@milianw milianw added the needs_info not enough info label Nov 11, 2023
@lievenhey
Copy link
Contributor

@milianw @GitMensch I guess this is related to #571

@GitMensch
Copy link
Contributor Author

As #574 is on the way to land in master, I'm closing this one. If I see this coming up later I can still reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug needs_info not enough info
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants