Hi Neil, Thanks for the comments.
> On May 31, 2017, at 8:21 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > > In addition to what others have mentioned, at this scale, you might get > significant gains by adjusting your s-expression language. > > For example, instead of this: > > (pmem_flush > (threadId 140339047277632) > (startTime 923983542377819) > (elapsedTime 160) > (result 0) > (addr 0x7fa239055954) > (length 1)) > (pmem_drain > (threadId 140339047277632) > (startTime 923983542378153) > (elapsedTime 83) > (result 0)) > > You could reduce consing by making each name-value pair be a single Racket > pair, rather than a proper list: > > (pmem_flush > (threadId . 140339047277632) > (startTime . 923983542377819) > (elapsedTime . 160) > (result . 0) > (addr . 0x7fa239055954) > (length . 1)) > (pmem_drain > (threadId . 140339047277632) > (startTime . 923983542378153) > (elapsedTime . 83) > (result . 0)) > > The proper list is what you'd want for a human language, and in most > applications the extra cost would be negligible, but you might have an > application in which it matters. I did consider using an association list representation for the attributes, but I'm depending on s-expression pattern matching for parsing the records. It's wonderfully convenient for this. I'm under the impression that `match` requires proper lists as input. While pattern-matching was wonderful for putting together the analysis tool quickly, I don't know how much of a bottleneck it is in the overall performance, so I may have to abandon it. > > Your file size grows by an extra 2 bytes per pair, though, and this will also > have a small additional I/O handling cost. > > Another thing you could do is, if one of your message types (like > `pmem_flush`) always/often has the same attribute names, is to make the > attributes "positional": > > #(pmem_flush 140339047277632 923983542377819 160 0 0x7fa239055954 1) > #(pmem_drain 140339047277632 923983542378153 83 0) > > If what's currently `pmem_flush` usually has the same attribute names, but > occasionally has an extra one, and you don't want to always be filling in > `#f`, maybe you want a `pmem_flush` with the positional attributes, and > `pmem_flush_extra` that has an extra positional attribute. The records are fixed-format, except that the trace record for system calls that take an I/O vector as an argument has a variable length list representing the struct iov array. > > If the possible variations of `pmem_flush` are more complicated, maybe > `pmem_flush` with positional, in the usual case; and `pmem_flush_named` with > named attributes or a hybrid of positional and named, in the complicated > cases. Then you have the various development costs of two ways of doing one > thing, but sometimes that happens in runtime performance optimization. > > I used a Racket vector here, to suggest fast direct access to the attribute > values, but if you used a list, you could destructure it to named > variables/slots with `apply` and `lambda` (or with `apply` and a `struct` > constructor, if that made sense). I found it essential to use named variables for the attributes, for my own sanity while writing the code. I'd appreciate a short example of what you mean by using `apply` and `lambda` to destructure the list. > > If you still find that this data interchange I/O is expensive, you can always > second-guess whether the reader is a win (over, say, a Unix-y > spaces-and-linefeeds format, or a binary format). But usually the reader is > fast. If I have to give up too much in programming convenience, I may as well just recode it in C++. Racket would still have been valuable in enabling me to quickly evolve the design. > BTW, some Algorithms 101 text once told me that constants don't matter, only > complexity, but that noble lie was just confusing. :) Best regards, -Steve -- Steve Byan steveb...@me.com Littleton, MA -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
