freenode/#shirakumo - IRC Chatlog
Search
20:41:30
Shinmera
in your story the depot now also needs to have a table to store where entries start/end or whatever rather than that info and whatever else just more naturally being part of the entry.
20:42:30
Shinmera
well now you're forcing every entry to have a start/end index even when there's no need to have one
20:43:31
Shinmera
my point is, why not just store all the info that's related to how to get the entry data in the entry itself
20:45:40
Shinmera
yes because in the above scenario we have depots that are connected to file-streams.
20:45:56
SAL9000
so you either need to duplicate the code -- file-stream version vs sequence version
20:46:32
Shinmera
you don't want to do the latter because it's slow and would just lead to more copying.
20:46:55
Shinmera
having two variants is not much more effort and is far more efficient because now you can create sub-entries that just address sub-sequences.
20:47:31
SAL9000
...would it make sense to provide something that quacks like a sequence but is backed by a file-stream?
20:48:28
Shinmera
in zippy I have an "io" structure that has its own API and has two implementations for vectors or for streams.
20:49:08
Colleen
github.com/Shinmera/zippy/b... Website (HTML), Title: zippy/io.lisp at master · Shinmera/zippy · GitHub
20:51:31
Shinmera
it's still not "very fast" because each individual call of these functions will dispatch, rather than dispatching once and then the rest knows.
20:52:07
Shinmera
the defmethod is because size is used elsewhere and I was too lazy to separate them.
20:53:16
SAL9000
...right, you still don't win unless you have two (identical) copies of the body of the caller, under an etypecase
20:54:19
Shinmera
having some magic that eliminates further dispatchers once it knows the type would be nice.
20:56:27
Shinmera
but usually emitting typecase is "good enough" and while slow at compiling, SBCL should eliminate the branching if it knows the variable type.