[Enhancement] Calendar initialization is very slow

[FabriBertani]

Hi @yurkinh, thank you for porting this plugin.

I want to point to this issue with the delay of the calendar initialization on mobile platforms, Android and iOS, this does not happen on Windows (I haven't tried on MacCatalyst yet).
I guess that this happens due to how the Grid is filled up with items in the ViewLayoutBase or something related to the MonthDaysView.

Currently, I don't have enough time to deep dive into this issue, but I noticed a few things, just using the SampleApp (I'm using SimplePage, WeekViewPage and AdvancedPage to run some tests):

• When the calendar is initialized, there are multiple calls to the garbage collector and lots of frames are skipped.

  • SimplePage (Android):
    

  • WeekViewPage (Android):
    

  • AdvancedPage (Android):
    

• When the calendar is initialized, it takes over 5 seconds to load the screen, even without the events list:

  • SimplePage (Android):
    

  • WeekViewPage (Android):
    

  • AdvancedPage (Android):
    

Also, worth mentioning that in the original plugin, there was a similar issue reported: [Bug] Calendar initializes very slow #101, but it seems that they fixed it because I've tested the Xamarin SampleApp and the load works really fast.

Thank you!

[yurkinh]

Hi @FabriBertani
Yes. I have noticed it too. Recently I have profiled it a bit with a freshly baked VScode extension .NET meteor 4 with profiler.
Yes, it takes time in layout engines when adding a day's view to the grid (and probably recalculating size).
I have no specific idea how to fix it but I want to play more with this profiler and days init

[yurkinh]

@FabriBertani Check please latest version(1.1.0)
I have improved performance and have few ideas how to improve it event more but it will require additional refactorings so stay tuned.

[FabriBertani]

Hey @yurkinh, I've tested it on Android but unfortunately, the issue remains.

[yurkinh]

@FabriBertani Are you testing it in Release mode?
performance improvements are not finished but I got much better numbers with speedscope including interesting insights where I can improve it even more

[FabriBertani]

@yurkinh Oh sorry my bad, I hadn't tried it in release mode, it works much better on release mode now.

[yurkinh]

@FabriBertani Great!
In debug mode Interpreter(needed for the hotreload stuff) is enabled by default hence it will be much slower and won't show true numbers.
While it is much better that it was before I still have a few ideas on how to improve it even more so tuned for the next updates)

[usefulBeeing]

Any news about performance optimizations coming soon @yurkinh ?? I can observe this initial lag even with a totally stripped out implementation:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:controls="clr-namespace:Plugin.Maui.Calendar.Controls;assembly=Plugin.Maui.Calendar" 
             xmlns:local="clr-namespace:MauiApp1"
             x:Class="MauiApp1.PageOne">
    
    <controls:Calendar HeaderSectionVisible="False"  />

</ContentPage>

I tried to implement it in a FlyoutItem scenario, once I click on the Calendar item, the lag happens and freezes the Flyout menu midway for a sec. I was able to capture this in a screenshot:

In VS Output window, I get the following:

[WindowOnBackDispatcher] OnBackInvokedCallback is not enabled for the application.
[WindowOnBackDispatcher] Set 'android:enableOnBackInvokedCallback="true"' in the application manifest.
[EGL_emulation] app_time_stats: avg=135.58ms min=1.61ms max=5320.69ms count=40
[TabLayout] MODE_SCROLLABLE + GRAVITY_FILL is not supported, GRAVITY_START will be used instead
[monodroid-assembly] open_from_bundles: failed to load assembly Plugin.Maui.Calendar.dll
Loaded assembly: /data/data/com.companyname.mauiapp1/files/.override/Plugin.Maui.Calendar.dll [External]
[monodroid-assembly] open_from_bundles: failed to load assembly CommunityToolkit.Mvvm.dll
Loaded assembly: /data/data/com.companyname.mauiapp1/files/.override/CommunityToolkit.Mvvm.dll [External]
[nyname.mauiapp1] Explicit concurrent copying GC freed 4445(337KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 4253KB/8506KB, paused 272us,41us total 9.246ms
[Choreographer] Skipped 33 frames! The application may be doing too much work on its main thread.
[MaterialButton] MaterialButton manages its own background to control elevation, shape, color and states. Consider using backgroundTint, shapeAppearance and other attributes where available. A custom background will ignore these attributes and you should consider handling interaction states such as pressed, focused and disabled
[MaterialButton] MaterialButton manages its own background to control elevation, shape, color and states. Consider using backgroundTint, shapeAppearance and other attributes where available. A custom background will ignore these attributes and you should consider handling interaction states such as pressed, focused and disabled
[MaterialButton] MaterialButton manages its own background to control elevation, shape, color and states. Consider using backgroundTint, shapeAppearance and other attributes where available. A custom background will ignore these attributes and you should consider handling interaction states such as pressed, focused and disabled
[MaterialButton] MaterialButton manages its own background to control elevation, shape, color and states. Consider using backgroundTint, shapeAppearance and other attributes where available. A custom background will ignore these attributes and you should consider handling interaction states such as pressed, focused and disabled
[nyname.mauiapp1] Explicit concurrent copying GC freed 4756(202KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 4783KB/9566KB, paused 387us,48us total 11.374ms
[nyname.mauiapp1] Explicit concurrent copying GC freed 3543(120KB) AllocSpace objects, 1(108KB) LOS objects, 49% free, 5019KB/10038KB, paused 333us,39us total 12.025ms
[Choreographer] Skipped 60 frames! The application may be doing too much work on its main thread.
[EGL_emulation] app_time_stats: avg=1616.77ms min=1616.77ms max=1616.77ms count=1
[OpenGLRenderer] Davey! duration=1609ms; Flags=0, FrameTimelineVsyncId=37453623, IntendedVsync=1898138819349616, Vsync=1898139369349594, InputEventId=0, HandleInputStart=1898139379196380, AnimationStart=1898139379226080, PerformTraversalsStart=1898139379515080, DrawStart=1898140295918680, FrameDeadline=1898138852682948, FrameInterval=1898139378569980, FrameStartTime=16666666, SyncQueued=1898140387040580, SyncStart=1898140387254480, IssueDrawCommandsStart=1898140387662280, SwapBuffers=1898140427279980, FrameCompleted=1898140428822680, DequeueBufferDuration=25100, QueueBufferDuration=248500, GpuCompleted=1898140428010880, SwapBuffersCompleted=1898140428822680, DisplayPresentTime=144115222452438154, CommandSubmissionCompleted=1898140427279980,
[OpenGLRenderer] Davey! duration=1083ms; Flags=0, FrameTimelineVsyncId=37453637, IntendedVsync=1898139386016260, Vsync=1898140386016220, InputEventId=0, HandleInputStart=1898140391760180, AnimationStart=1898140391780480, PerformTraversalsStart=1898140437463780, DrawStart=1898140438257780, FrameDeadline=1898140452682884, FrameInterval=1898140391076880, FrameStartTime=16666666, SyncQueued=1898140463933380, SyncStart=1898140464097780, IssueDrawCommandsStart=1898140464341180, SwapBuffers=1898140467937680, FrameCompleted=1898140469218380, DequeueBufferDuration=19200, QueueBufferDuration=593400, GpuCompleted=1898140469137480, SwapBuffersCompleted=1898140469218380, DisplayPresentTime=0, CommandSubmissionCompleted=1898140467937680,

While doing a little research, I found the following discussions to be interesting:

• The application may be doing too much work on its main thread ...
• monodroid-assembly open_from_bundles: failed to load assembly ...
• MaterialButton manages its own background ...
• OpenGLRenderer: Davey ...

[yurkinh]

Hi @usefulBeeing
Are you testing it in Release or debug mode?
Cause in debug mode it will be much - much slower.
I have done a few optimizations since this ticket was opened and plan a few more. Currently, I want first to fix the most critical and urgent issues and then I will come back to the perf optimisations

[usefulBeeing]

Thank you @yurkinh. Glad to hear you have a plan and not abandoning this great plugin! Except for the lag I described, which happens in both debug and release mode alike, I find your plugin to be very light weight compared to other products I tried in the past.