updates.

[silc.git] / silc_optimize

diff --git a/silc_optimize b/silc_optimize
new file mode 100644 (file)
index 0000000..655ac71
--- /dev/null
+++ b/silc_optimize
@@ -0,0 +1,70 @@
+SILC Optimizations:
+===================
+
+o Library
+
+       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 should 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 and maybe sending too, which the library will call
+         when necessary.  This way we can move the data handling in one 
+         place.
+
+o Server
+
+       o When processing the decrypted and parsed packet we call the
+         silc_server_packet_parse_type function.  This function has a 
+         huge switch statement.  Replace this switch statment with pre-
+         defined table of function pointers where each of the slot
+         in the table represents the packet type (1 for packet type
+         value 1, 2 for value 2 and so on), and call the callback
+         found in the slot.  In this case we can do one-to-one mapping
+         of packet types to correct function.
+
+       o Same optimizations could be done with notify packets which
+         has huge switch statement too.  Same kind of table of notify
+         callbacks would be very easy to do, and achieve one-to-one
+         mapping of notify types.
+
+       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.