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

[GitMensch]

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 ):

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.

[milianw]

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]

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]

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]

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]

ping?

[lievenhey]

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

[GitMensch]

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.