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

DataGrid performance on attached to visual tree. #16139

Open
IZIDIA opened this issue Jun 26, 2024 · 2 comments · May be fixed by #16140
Open

DataGrid performance on attached to visual tree. #16139

IZIDIA opened this issue Jun 26, 2024 · 2 comments · May be fixed by #16140

Comments

@IZIDIA
Copy link

IZIDIA commented Jun 26, 2024

Describe the bug

Hello. I'm using a DataGrid in my project and have noticed a performance hit when my table is attached to a visual tree. I ran a dotTrace measurement inside the Rider IDE and noticed that the InitializeElements method was taking a long time.

The commit that was made earlier solves one of the problems: #9527

pull:
almightyju@e9f2cb3

But I believe there is a bug in this commit.

InitializeElements(bool recycleRows) now we use false.

This leads to the fact that every time we connect to the visual tree, we build the columns in the table all over again. But at the same time, we only need to update the rows. We need use only RefreshRows inside method InitializeElements(bool recycleRows).

And so we must replace this:

        protected override void OnAttachedToVisualTree(VisualTreeAttachmentEventArgs e)
        {
            base.OnAttachedToVisualTree(e);
            if (DataConnection.DataSource != null && !DataConnection.EventsWired)
            {
                DataConnection.WireEvents(DataConnection.DataSource);
                InitializeElements(false /*recycleRows*/);
            }
        }

TO:

        protected override void OnAttachedToVisualTree(VisualTreeAttachmentEventArgs e)
        {
            base.OnAttachedToVisualTree(e);
            if (DataConnection.DataSource != null && !DataConnection.EventsWired)
            {
                DataConnection.WireEvents(DataConnection.DataSource);
                InitializeElements(true /*recycleRows*/);
            }
        }

My measurements using Stopwatch (I was just switching between tabs):

   protected override void OnAttachedToVisualTree(VisualTreeAttachmentEventArgs e)
        {
            base.OnAttachedToVisualTree(e);
            if (DataConnection.DataSource != null && !DataConnection.EventsWired)
            {
                DataConnection.WireEvents(DataConnection.DataSource);
                var timer = new Stopwatch();
                timer.Start();
                InitializeElements(false /*recycleRows*/);
                timer.Stop();
                Debug.WriteLine(timer.Elapsed);
            }
        }

InitializeElements(false /*recycleRows*/);

00:00:01.5716088
00:00:01.8027466
00:00:01.4541749
00:00:01.6555272
00:00:01.6144568

InitializeElements(true /*recycleRows*/);

00:00:00.1817455
00:00:00.1990262
00:00:00.1896094
00:00:00.2103093
00:00:00.1970060

To Reproduce

Open the ready-made DataGrid examples in the avalonia project and start switching between tabs.

Expected behavior

No response

Avalonia version

11.1-rc1

OS

Windows

Additional context

No response

@IZIDIA IZIDIA added the bug label Jun 26, 2024
IZIDIA added a commit to IZIDIA/Avalonia that referenced this issue Jun 26, 2024
@IZIDIA IZIDIA linked a pull request Jun 26, 2024 that will close this issue
3 tasks
@IZIDIA
Copy link
Author

IZIDIA commented Jun 26, 2024

By the way. Removing the InitializeElements(false /*recycleRows*/); line completely solves the scrolling problem. When you switch to another tab and back. Your scrolling position remains in the same place. I plan to spend some more time solving this problem.

See #15218

@IZIDIA
Copy link
Author

IZIDIA commented Jun 27, 2024

This should solve both problems. #16140

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants