- o Optimizations in Libraries
-
- o There is currently three (3) allocations per packet in the
- silc_packet_receive_process, which is used to process and
- dispatch all packets in the packet queue to the parser callback
- function. First allocation is for parse_ctx, second for the
- SilcPacketContext, and third for packet->buffer where the actual
- data is saved.
-
- The parse_ctx allocation can be removed by adding it as a
- structure to the SilcPacketContext. When the SilcPacketContext
- is allocated there is space for the parse context already.
-
- The silc_packet_context_alloc could have a free list of
- packet contexts. If free packet context is found from the list
- it is returned instead of allocating a new one. The library
- could at first allocate them and save them to the free list
- until enough contexts for smooth processing exists in the list.
- This would remove a big allocation since the structure is
- quite big, and even bigger if it would include the parse_ctx.
-
- The packet->buffer can be optimized too if the SilcBuffer
- interface would support free lists as well. Maybe such could
- be done in the same way as for SilcPacketContext. The
- silc_buffer_alloc would check free list before actually
- allocating new memory. Since the packets in the SILC protocol
- usually are about the same size (due to padding) it would be
- easy to find suitable size buffer from the free list very
- quickly.
-
- These naturally cause the overal memory consumption to grow
- but would take away many allocations that can be done several
- times in a second.
-
- o Move the actual file descriptor task callback (the callback that
- handles the incoming data, outgoing data etc, that is implemnted
- in server and client separately (silc_server_packet_process and
- silc_client_packet_proces)) to the low level socket connection
- handling routines, and create an interface where the application
- can register a callbacks for incoming data, outoing data and EOF
- receiving, which the library will call when necessary. This way
- we can move the data handling in one place.
-
- o Add silc_id_str2id to accept the destination buffer as argument
- and thus not require any memory allocation. Same will happen
- with silc_id_payload_* functions.
-
- o Remove the `truelen' field from SilcBuffer as it is entirely
- redundant since we can get the true length of the buffer by
- doing buffer->end - buffer->header. Add SILC_BUFFER_TRUELEN
- macro instead. Consider also removing `len' field too since
- it effectively is buffer->tail - buffer->data, and adding
- SILC_BUFFER_LEN macro can do the same. These would save
- totally 8 bytes of memory per buffer.
-
- o Scheduler can be optimized for FD tasks by changing the fd_queue
- to SilcHashTable instead of using linked list. We need to do
- one-to-one mapping of FD to task and hash table is more efficient
- for this usage.
-
- Also redefine the silc_select to perhaps return a separate
- structure of the events that actually occurred, instead of
- returning the events in the fd_list which is then traversed
- in the generic code to find the changed events. This can be
- made faster by having own struct which includes only the
- changed events, thus the tarversing is faster since the whole
- fd_list is not traversed anymore (it is still traversed in the
- silc_select but at least it removes one extra tarversing later
- for the same list).
-
- o Optimizations in Server
-
- o Remove the big switch statement from the function
- silc_server_packet_parse_type and replace it with predefined
- table of function pointers where each of the slot in table
- represents the packet type value.
-
- Same could be done with notify packets which has big switch
- statement too. Same kind of table of notify callbacks could be
- done as well.
-
- o The parser callback in the server will add a timeout task for
- all packets. It will require registering and allocating a
- new task to the SilcSchedule. Maybe, at least, for server
- and router packets the parser would be called immediately
- instead of adding it to the scheduler with 0 timeout. It
- should be analyzed too how slow the task registering process
- actually is, and find out ways to optimize it.
-
- o The SERVER_SIGNOFF notify handing is not optimal, because it'll
- cause sending of multiple SIGNOFF notify's instead of the one
- SERVER_SIGNOFF notify that the server received. This should be
- optimized so that the only SERVER_SIGNOFF is sent and not
- SIGNOFF of notify at all (using SIGNOFF takes the idea about
- SERVER_SIGNOFF away entirely).