IRC channel logs
2026-01-15.log
back to list of logs
<lechner>Hi, I have a long association list of symbols. At what point should I use a hash-table instead, please? <old>lechner: I saw a benchmark on that recently. It will depends on what you do with it and how it's allocated. <old>I think it was in the ~40 that you might want to make to hashtable <old>I think for example, if your alist is fixed in size and is allocated with literals, you can probably scale better than if you dynamically generare it <old>Probably the allocation for literals will make it so that you hit less cache line for general access. But even with that, I would say that whenever you start going in 10^2 values, you are better off with hash-table <mwette>lechner: If this is for foo-symtol-tab you can add (define bar-htab (alist->hashq foo-symbol-tab)) to your .nyacc (aka .ffi) file. <mwette>nyacc-3.02.0 released today; next effort: revisit C pre-processor <adhoc>mwette: is that all written in guile ? <old>mwette: I don't why, but your mail render some NO-BREAK SPACE (codepoint 160, #o240, #xa0) in some place. Is this intended? <mwette>old: sorry, my email client is thunderbird. I should send unformatted, but I get lazy. (I surrendered to the populist email clients a while ago; I used RMAIL for a long time before that.) <old>whish Emacs could just not print it as a red underline <rlb>old: offhand, I'd guess that may be configurable, but I don't know the context all that well. <lechner>old / rlb / thanks! my alist has 5442 elements. <janneke>how do i get more than 11 stack frames on a backtrace? the essential information seems to be chopped-off.. <mwette>janneke: does ,bt accept a `#:full #t' argument <janneke>mwette: ah that could be, i'm running from a compilation buffer so, hmm <old>where is this documented? <janneke>(when you know what to search for, it's kinda easy :) <old>oh right, that's kind of nested in the documentation <janneke>if i had found it, i wouldn't have asked it here... <old>I've been reading this manual for many years now, I keep finding stuff I've overlook. like this <janneke>iwbn if "6.11.7 Returning and Accepting Multiple Values" would (also) suggest srfi-71 instead of/next to srfi-8, /me thinks <daviid>fwwi, imo, next to, not instead, receive is by far the best (to me) ...