===========
Performance
===========

The current maintainer of the CalDAV library was born in an age where memory and CPU was limited resources.  CPU and memory comes cheaply today (read https://www.aardvark.co.nz/daily/2025/0611.shtml to see what I mean).  The CalDAV and iCalendar protocols weren't really written for lean computing in the first place.  If you need something that can run around on what used to be a bleeding edge supercomputer some decades ago, you probably need to scrap those standards and write your own optimized calendaring standard and your own server and client for it - and this probably has to be done in C, not in Python.

Still, sometimes all the extra bloat I've added to the CalDAV library makes me cringe a bit.  If you have issues with performance, please reach out (see the :ref:`contact:contact` document).

Some thoughts:

* While CPU and memory comes cheaply today, latency is often a problem.  Creating server requests and particularly initiating TCP connections are typically costly.  There are a number of places in the code where it may be possible to reduce the number of requests.  As of v3.x, **niquests** is used by default for HTTP communication, bringing HTTP/2 and HTTP/3 support, this should make things more snappy.  See the :doc:`http-libraries` document for details.  It's also possible to enable multiplexing by enabling `http.multiplexing` in the server `features` setting.  (it's disabled by default because a handful of servers out there can't handle the authentication if multiplexing is enabled)
* In the early days almost all the necessary handling of icalendar data was done by accessing it as ``event.data``.  This may be the most efficient - but the ``vobject`` was also utilized.  Due to popular demand, plus the fact that ``vobject`` was not mainained for a while, ``icalendar`` took over.  I can imagine it does takes some CPU to convert the data between ical strings and instances.  This is done every time the data is accessed in a different format.  For performance reasons, I was initially not very happy to use the icalendar library for doing simple things like fetching the UID from an event - but I've come to think that this is necessary.  Now the problem is that every here and there there may still be some old code accessing ``event.data`` rather than ``event.icalendar_instance``.  This probably causes the burning of quite a lot of CPU cycles!