Julien, hi. Could you please test it and if you will confirm the problem please make a perfgraph for this case. Thanks

This seems difficult to bisect.

I adapted a script from https://wiki.documentfoundation.org/QA/Bibisect/Automation like this:

#!/usr/bin/env bash
# bisect_perf.sh  Called with 3+1 parameters: "file.ext" good-time timeout-time [fix]
    fileext=$1 ;   goodtime=$2 ; timeouttime=$3 ; regfix=$4
    if [[ $regfix = "fix" ]]; then before=1; after=0; else before=0; after=1; fi
    # timeout takes seconds by default
    timeout $timeouttime bash -c ' OOO_EXIT_POST_STARTUP=1 SAL_USE_VCLPLUGIN=gen ./instdir/program/soffice --norestore "$@" ' bash  /home/user/libobugs/"$fileext"
    status=$? ;         echo "$status"
    exptime=$SECONDS
        if [ $status = 124 ] ; then
                echo "timeout in $timeouttime, done in $exptime sec" ; exit $before
        elif [ $status = 134 ] ; then
            echo "done in $exptime sec" ; exit $after
        elif [ $status = 42 ] ; then
            if (( $exptime < $goodtime ))  ; then
                echo "opens fast in $exptime sec" ; exit $before
            elif (( $exptime > $goodtime ))  ; then
                echo "opens slow in $exptime sec" ; exit $after
            else echo "error"
            fi
        else echo "other exit code"
    git reset --hard
    fi

Then started a run with it in the Linux 24.2 repo, which seemed to be the one where it slowed down:

git bisect start master oldest && git bisect run /path/to/bisect_perf.sh "Тест.xlsx" 80 240

Limit for good being 80 secs and timeout being 4 minutes. However, the results were not reliable in the actual bisecting run. The original bad time I saw was like 2min30sec, but in the bisect run I got many timeouts, so going over 4 mins. Doing the run a couple of times and checking the blamed vs. previous commit revealed the result was incorrect.

I may continue investigating this.

Ok, checking with linux-64-25.2 repo, there was a further pessimisation, like +30 secods. This time, I could reliably bisect it. The blamed commit is
 290c8f6e048fedf63437e3fdf629555ac89dd3ad
ITEM: Change SfxItemSet to use unordered_set

Maybe it's not fair to use the "Regression By" field in this case as it's the huge rework project.

Noel's very recent c3e8dbc139c3b1644ea07101a8c1111572ffa017 seems to have improved the opening time by more than 10 seconds for me.

(In reply to Buovjaga from comment #3)
> Ok, checking with linux-64-25.2 repo, there was a further pessimisation,

I saw the same bad time in 24.2 too...

I tried both buttons with "скачать", it does nothing so I can't test the file.

Created attachment 195449 [details]
Perf flamegraph

Spends a lot of time getting optimal height and figuring out RichStrings at least.

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a7de9cc5e89cd0d0c2f6363b2c0cc265c528b121
CPU threads: 8; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded