freenode/#clasp - IRC Chatlog
Search
15:45:33
drmeister
If I compile-file this... (defmethod foo () (bar)) (defmethod bar () (baz)) (defmethod baz () (error "in baz"))
15:49:44
drmeister
It doesn't look too bad after that. I can single step instructions from the start of FOO to BAR and it's not too bad, if a bit difficult to follow (probably because of optimization).
15:59:23
drmeister
I think the APPLY is coming from here https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/closfastgf.lsp#L481
16:31:00
drmeister
Generic function dispatch isn't the source of our slowness - but now it looks really streamlined.
17:39:09
drmeister
Everything is pushed through to testing (1) fastgf is now fully operational and (2) backtraces look great once dispatchers are fully compiled.
18:02:09
drmeister
Once we find it, and kill it, and dance on its grave - fastgf will live up to its name.
18:04:40
drmeister
The problem has been that the backtraces gathered from tracing have been unmanageable.
18:05:01
drmeister
They are full of return addresses with no symbol information (due to the JIT) and C++ frames.
18:06:53
drmeister
I'm capturing JIT events now and generating a symbol table and now I'm writing a symbolicator program that will text swap addresses of the form 0xYYY to symbol names. symbolicator -s symbol-table-file <file-full-of-0xYY >file-with-symbol-names
18:07:56
drmeister
I did your single step through instructions to look at the fastgf call sequence - it's very short now.
18:08:56
drmeister
Profiling fastgf calls relative to regular calls in sbcl - generic function calls are about 3x slower than regular calls.
18:09:46
beach
Good luck. I am off to spend time with my (admittedly small) family. I'll be back tomorrow morning (UTC+2).
18:09:55
drmeister
Don't worry about responding - I'm dumping this into this channel for the log so that Bike and I can take it apart tomorrow.