Here are my notes from the Golang Boston Meetup 2017-06-27 debugging meeting, such as they are. Corrections/elaborations welcome.
Notes from debugging group. TLDR: fmt.Println is still very common; nobody in the room knew everything -- i.e., there's debugging tricks and techniques that you probably don't know; there's ever so much "upside potential" in the current tools.
Techniques mentioned:
A common pattern in my CouchDB view reductions is to "merge" together the objects generated by the map function while preserving the original form, and only query that view with group=true. It's easiest to write the view reductions naively, so they continue merging the data all the way up to the top-level reduction (group=false).
But because CouchDB stores its b+trees with the reduction for each b+tree node stored in that node, moderately sized objects can result in a lot of extra writes to disk, and moderately complicated functions can cause a lot of wasted CPU time in the indexer running merge javascript that is never queried. Re-balancing the b+tree compounds this problem. This can cause the initial creation of large indexes to slow down tremendously. If the index becomes terribly fragmented, this will also affect query speed.
One solution: once the reduction is beyond the keys at the group level I care about, stop running the merge code and return the simplest data that works (e.g. null or
| // This is the map function to give to CouchDB: | |
| function(doc) { | |
| function xemit(key, val) { | |
| emit(key, {key: key, val: val}); | |
| } | |
| // Your code goes here, working with the doc provided. | |
| // Use xemit(key, value) instead of CouchDB's emit | |
| // ... |
