Error stack performance problem

[khasanovbi]

Hi, I used the hashtable from your library. When I use the hashtable and often got hit miss, the library generates a lot of stack. It turns out to be an expensive operation.
Could we remove it and just use error wrapping instead?

[jeffwilliams]

I encountered the same issue, but I realized the library provides a way to override how the errors are created. For my own purposes I didn't care about which type of error was occurring, just whether one was occurring. Here's the code I used to speed up the handling; you can use it as a reference for your own needs:

import (
	"fmt"
	"github.com/timtadh/data-structures/errors"
)

func init() {
	installFasterErrorFormattersInTimtadhDataStructures()
}

var simpleError = fmt.Errorf("operation failed")
func simpleErrorFmter(a ...interface{}) error {
	return simpleError
}

// installFasterErrorFormattersInTimtadhDataStructures changes the error formatters
// used by the github.com/timtadh/data-structures packages so that they are faster.
// The default ones generate a stacktrace each time a hash entry is not found or removed
func installFasterErrorFormattersInTimtadhDataStructures() {
	for k := range errors.Errors {
		errors.Errors[k] = simpleErrorFmter
	}

}

That being said, I think it might be worth adding a note to the README that suggests that something like this is worthwhile to do for performance reasons.

[timtadh]

Hi! Glad you are both finding the library useful. Jeff I would be happy to accept a pull request to either add your snippet to the README or we could change the default error formatter. The stack traces are often super useful for debugging. But since the errors are generated every time you have a miss they are pretty heavy weight. So for these default errors maybe they should just be a fixed string.