From: Dominic S. <dom...@gm...> - 2009-09-14 19:13:38
|
Hi, I'm looking into optimizing an application that's a pretty heavy user of clos, and I see quite a bit of time being spent in sb-pcl:safe-method-specializers. I see that there are singleton instances for class-standard-method, class-standard-reader-method and several others in a list called sb-pcl:*standard-method-classes*. The interesting thing to me is that all the methods to get safe-method-specializers, safe-fast-functions etc scan the *standard-method-classes* and do a clos-slots-ref instead of just using the accessor. Like this: (defun safe-method-specializers (method) (let ((standard-method-classes *standard-method-classes*) (class (class-of method))) (if (member class standard-method-classes) (clos-slots-ref (get-slots method) *sm-specializers-index*) (method-specializers method)))) Can we just change this function to be this? (defun safe-method-specializers (method) (method-specializers method)) It seems to be a little faster according to sprof in my application. Thanks, -Dominic |
From: Christophe R. <cs...@ca...> - 2009-09-15 07:33:53
|
Dominic Schulz <dom...@gm...> writes: > Can we just change this function to be this? > (defun safe-method-specializers (method) > (method-specializers method)) > > It seems to be a little faster according to sprof in my application. Briefly: no. The point of the SAFE-<accessor> functions is that users of the MOP are allowed to define methods on those accessors, and also those accessors are part of the protocol for computing some aspect of method dispatch (e.g. effective method computation, or applicable methods, or similar). Thus, we need the SAFE-<accessor> variants to be able to break metacircles, where a user defines a method on some accessor, the system needs to compute an effective method for that accessor, and needs then to be able to call that accessor (but it can't because the effective method hasn't been computed yet). In the case of your application, I'd try looking at why method specializers are being repeatedly reaccessed... Cheers, Christophe |
From: Nikodemus S. <nik...@ra...> - 2009-09-15 08:27:34
Attachments:
safe-method-foo-micro-opt.patch
|
2009/9/15 Christophe Rhodes <cs...@ca...>: > In the case of your application, I'd try looking at why method > specializers are being repeatedly reaccessed... That said, current SAFE-FOO implementations are slower than they need to be: in the worst case they access eight specials, the MEMBER call uses EQL for comparison, and GET-SLOTS has an unneeded branch. Attached patch does a bit of micro-optimization to take care of those issues. (Similar things could be done for some other metacircularity-defence mechanisms.) Does it make things less slow for you, Dominic? It would also be interesting to know which call-paths to SAFE-METHOD-SPECIALIZERS are featuring in your profiles: SB-SPROF can provide this information. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2009-09-15 11:08:23
|
2009/9/15 Christophe Rhodes <cs...@ca...>: > In the case of your application, I'd try looking at why method > specializers are being repeatedly reaccessed... That said, the SAFE-FOO implementations were slower than they need to be: in the worst case they access eight specials, and the MEMBER call uses EQL for comparison. I've committed as 1.0.31.9 a patch that patch does a bit of micro-optimization to take care of those issues, some some related ones. Does it make things better for you, Dominic? It would also be interesting to know which call-paths to SAFE-METHOD-SPECIALIZERS are featuring in your profiles: if you run SB-SPROF using the :GRAPH output option the callers and callees of profiled functions are reported as well. Cheers, -- Nikodemus |