silc_optimize

   1 SILC Optimizations:
   2 ===================
   3
   4 o Library
   5
   6         o There is currently three (3) allocations per packet in the
   7           silc_packet_receive_process, which is used to process and
   8           dispatch all packets in the packet queue to the parser callback
   9           function.  First allocation is for parse_ctx, second for the
  10           SilcPacketContext, and third for packet->buffer where the actual
  11           data is saved.
  12
  13           The parse_ctx allocation can be removed by adding it as a
  14           structure to the SilcPacketContext.  When the SilcPacketContext
  15           is allocated there is space for the parse context already.
  16
  17           The silc_packet_context_alloc should have a free list of
  18           packet contexts.  If free packet context is found from the list
  19           it is returned instead of allocating a new one.  The library
  20           could at first allocate them and save them to the free list
  21           until enough contexts for smooth processing exists in the list.
  22           This would remove a big allocation since the structure is
  23           quite big, and even bigger if it would include the parse_ctx.
  24
  25           The packet->buffer can be optimized too if the SilcBuffer
  26           interface would support free lists as well.  Maybe such could
  27           be done in the same way as for SilcPacketContext.  The
  28           silc_buffer_alloc would check free list before actually
  29           allocating new memory.  Since the packets in the SILC protocol
  30           usually are about the same size (due to padding) it would be
  31           easy to find suitable size buffer from the free list very
  32           quickly.
  33
  34           These naturally cause the overal memory consumption to grow
  35           but would take away many allocations that can be done several
  36           times in a second.
  37
  38         o Move the actual file descriptor task callback (the callback that
  39           handles the incoming data, outgoing data etc, that is implemnted
  40           in server and client separately (silc_server_packet_process and
  41           silc_client_packet_proces)) to the low level socket connection
  42           handling routines, and create an interface where the application
  43           can register a callbacks for incoming data, outoing data and EOF
  44           receiving and maybe sending too, which the library will call
  45           when necessary.  This way we can move the data handling in one
  46           place.
  47
  48 o Server
  49
  50         o When processing the decrypted and parsed packet we call the
  51           silc_server_packet_parse_type function.  This function has a
  52           huge switch statement.  Replace this switch statment with pre-
  53           defined table of function pointers where each of the slot
  54           in the table represents the packet type (1 for packet type
  55           value 1, 2 for value 2 and so on), and call the callback
  56           found in the slot.  In this case we can do one-to-one mapping
  57           of packet types to correct function.
  58
  59         o Same optimizations could be done with notify packets which
  60           has huge switch statement too.  Same kind of table of notify
  61           callbacks would be very easy to do, and achieve one-to-one
  62           mapping of notify types.
  63
  64         o The parser callback in the server will add a timeout task for
  65           all packets.  It will require registering and allocating a
  66           new task to the SilcSchedule.  Maybe, at least, for server
  67           and router packets the parser would be called immediately
  68           instead of adding it to the scheduler with 0 timeout.  It
  69           should be analyzed too how slow the task registering process
  70           actually is, and find out ways to optimize it.