Drop useless data in a side-effecting map ¨
This is a fairly obvious tip, but I've still needed to think of it when applying some code to much more data than it'd normally deal with. In one case, 20+GB of memory used turned into negligible use. Consider:
•Show¨↕100
# 100 lines
⟨ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ⟩
# we only wanted the side effect, but this big list was still built
{•Show 𝕩⋄@}¨↕100
# 100 lines
""
≠{•Show 𝕩⋄@}¨ ↕100
# 100 lines
100
# that's a 100-byte string filled with zeroes, which at least might be smaller data to build
o←⟨•Show¨↕100, {•Show 𝕩⋄@}¨↕100⟩ ⋄ •internal.Info¨ o
⟨ "fff7: refc:2 type:23=i8arr alloc:128" "fff7: refc:2 type:26=c8arr alloc:128" ⟩
# though, not in this case?
# best for space while reversing the order of operations:
@ {•Show 𝕨}´ ↕100
# 100 lines
0
You could use •_while_ to retain no data at all, but I'd no longer be as sure that this won't change something else about the code's performance or resource use.
Large allocations can be a significant CPU cost as well! In the code that prompted this tip, )profile showed showed 10x as much time spent on the lines building unnecessary lists, even on the smaller datasets where I hadn't minded the performance.
Random CBQN notes
discord (very minor note that in CBQN currently {𝕤⋄2+2} is like maybe 0.6ns slower than {𝕊: 2+2} as it still does code to pointlessly load & discard the 𝕤 variable; at some point in the indeterminate future that'll hopefully stop being a thing, but for now it is. Another advantage (or sometimes disadvantage) is that {𝕊: } is an error, whereas {𝕤⋄} returns the 𝕤)
discord ⚇ is currently very slow in CBQN (outside of ⚇0 which gets to be as fast as the equivalent ¨es)
discord a whole 100ns go to justraylib.DrawLineEx; not calling, just the namespace lookup.. which is O(n) in CBQN for a namespace withnfields
andraylibhas a lot of fields
Conclusion: avoid namespace lookups in explicit functions. In a tacit definition the cost is only paid once.