Bugzilla

(In reply to Richard Leger from comment #28)
> (In reply to Arthur K. [He/Him] from comment #27)
> > How is this behaving in 91.0b6?
> Will test again and revert back...

I have tested again in TB 91.0b6 (64-bit). The situation remain the same.

**58 Requests** for 10MB+ data in 1.90mn according to devtool networking for loading one CalDAV calendar containing 4000+ items.

Stopwatch shows calendar takes about **2mn** to load (calendar items appear in the view only after that time lapse) with default TB settings (unifinder set to Event in the next 7 days - no column selected for ordering). No pause observed between network requests.

Setting up unifinder to All Events and ordering by Title column still increase drastically the time it takes to load the calendar because after each batch TB order the least instead of waiting for all batch to load prior ordering the list. The number or network requests remain the same but some pause appears between them at some point... as TB is processing previous request...

I believe that increasing the batch size from 100 to 500 or 1000 would reduce the number of network request and accelerate the loading of the calendar. But I don't know how that would impact TB to parse each .ics items in such high quantity. In theory it shouldn't but I haven't been able to try.

I hope that make sense.

(In reply to Richard Leger from comment #28)
> (In reply to Arthur K. [He/Him] from comment #27)
> > How is this behaving in 91.0b6?
> Will test again and revert back...

I have tested again in TB 91.0b6 (64-bit). The situation remain the same.

**58 Requests** for 10MB+ data in 1.90mn according to devtool networking for loading one CalDAV calendar containing 4000+ items.

Stopwatch shows calendar takes about **2mn** to load (calendar items appear in the view only after that time lapse) with default TB settings (unifinder set to Event in the next 7 days - no column selected for ordering). No pause observed between network requests.

Setting up unifinder to All Events and ordering by Title column still increase drastically the time it takes to load the calendar because after each batch TB order the least instead of waiting for all batch to load prior ordering the list. The number or network requests remain the same but some pause appears between them at some point... as TB is processing previous request...

I believe that **increasing the batch size from 100 to 500 or 1000 would reduce the number of network requests** and accelerate the loading of the calendar. But I don't know how that would impact TB to parse each .ics items in such high quantity. In theory it shouldn't but I haven't been able to try.

I hope that make sense.