freenode/#sicl - IRC Chatlog
Search
13:08:42
scymtym
yesterday i thought of a funny way of speeding up the "applicable methods must not change check" in CALL-NEXT-METHOD: https://github.com/scymtym/sbcl/blob/6ed3332f053b555e2f605b64456989d14b72f1bf/src/pcl/cnm.lisp#L26 . i thought people here might be interested. does this matter in practice? yes: https://techfak.de/~jmoringe/clim.flamegraph-medium-draw-rectangle-star.png
13:42:42
scymtym
the first link is an implementation sketch. the second shows a profile that illustrates the performance problem of the current approach (which basically calls COMPUTE-APPLICABLE-METHODS twice for each CALL-NEXT-METHOD call that "changes" the required arguments)
13:43:52
beach
I will study it later, because it looks important, but I am about to take a break now after a long morning which included cooking for my lunch guests and entertaining them.
13:52:01
Bike
i saw you post this in #sbcl before but i didn't actually get it... this seems pretty clever
13:52:50
Bike
i'm wondering if we couldn't speed it up in sicl using the call history, but i guess it could technically be possible to c-n-m with arguments that are different classes but have the same applciable methods
13:54:10
scymtym
i also feel like i am doing this the lazy way by defining a generic function instead of using a lower-level mechanism such as the PCL cache directly
13:58:19
scymtym
in any case, the slow path (that is some arguments being unEQL) seems to come up rarely. but when it does, it hurts a lot
14:01:01
Bike
when does that.... ohhh, twiddling with keys... i see. i wouldn't have even thought of that case
14:05:02
scymtym
pairwise EQL comparison of the required arguments was already there and is definitely the more important trick. i'm only trying to improve the slow-slow-slow path or something like that
14:23:50
Bike
well, in sicl we probably couldn't do anything much faster than a generic function call, so it would probably look like this anyway
14:35:07
Bike
i wonder, in the slow path is it more common to call with arguments that specailize the same? maybe that specifically could be sped up?
14:47:21
Bike
i guess you could have one checker per applicable method set and save a bit of dispatch, but that probably doesn't matter
14:51:37
scymtym
this is so rare that i want to make it as simple as possible rather than as fast as possible. the only cases hitting the slow path i have seen so far have been like (call-next-method (1+ x) (1+ y) …) or similar
14:54:06
Bike
i don't think clasp does any checking at all at the moment. i'll have to at least put in the slow path and the eql check
14:55:38
scymtym
oh, in SBCL, it is probably the slow*5 path instead of the slow*3 path since, in addition to the other preconditions, the check is only performed in safe code