[Erc-help] Re: Backend related musings.

[Lawrence M. <we...@gm...>]

Jeremy Maitin-Shepard wrote:

> Lawrence Mitchell <we...@gm...> writes:

>> ERC-CALL-HOOKS is then simplified a great deal, rather than
>> looking to see if a response has an associated hook, we just do
>> (gethash RESPONSE erc-server-responses).  Falling back, as
>> before, on ERC-DEFAULT-SERVER-HOOK.

> Perhaps we should figure out how creating an interning a symbol and
> then calling `funcall' compares performance-wise to using an elisp hash
> table.

Well, since we don't support Emacs 20, hashtables are a builtin
type, so they should be pretty quick.  A short bit of testing
would appear to confirm my gut feeling:

(defun my-intern (s)
  (or (intern (format "erc-server-%s" s))
      'erc-default-server-hook))

(defvar my-hashtable (make-hash-table :test #'equal))

(defun my-gethash (s)
  (gethash s my-hashtable 'erc-default-server-hook))

(puthash "MOTD" 'erc-server-MOTD my-hashtable)

(mapc 'byte-compile '(my-intern my-gethash))

(loop repeat 100000
      do (progn (my-gethash "MOTD")
                (my-intern "MOTD")))

Gives (via elp):

Function Name  Call Count  Elapsed Time  Average Time
=============  ==========  ============  ============
my-intern      100000      0.4657480000  4.657...e-06
my-gethash     100000      0.1717670000  1.717...e-06

I'm going to assume that FUNCALLing isn't any different
depending on where you get the argument from :).

So hashtables are (about) a four-fold performance win, though,
tbh, the difference is so small that I don't think its much of a
problem either way.  What I would note, however, is if one ever
decides to no longer call things erc-server-FOO, then we only
need to change stuff in one place (deferc-response-handler).  I
think the abstraction win is probably a bigger deal than any
small performance gains.

-- 
Lawrence Mitchell <we...@gm...>