Our data structures and function/method signatures make a lot of use of Strings. This is good enough to work, but since essentially none of these strings are ever modified, we can probably save a lot on memory and performance by avoiding copies using &str and interned strings (though given how short most of these strings likely are, it's possible the overhead of the latter would be too heavy).
Our data structures and function/method signatures make a lot of use of `String`s. This is good enough to work, but since essentially none of these strings are ever modified, we can probably save a lot on memory and performance by avoiding copies using `&str` and interned strings (though given how short most of these strings likely are, it's possible the overhead of the latter would be too heavy).
Thinking about it a bit more, I think there is definitely some string interning we want to do, at the very least for onion addresses. This readme has some comparisons of features, but not performance. I don't think we actually need multithreaded interning, at least for clients and peers, since we should be getting all strings we'll encounter at initialization. The server might though, since it doesn't have an explicit registration phase (though we could also just not intern on the server).
Thinking about it a bit more, I think there is definitely some string interning we want to do, at the very least for onion addresses. [This readme](https://docs.rs/simple-interner/latest/simple_interner/) has some comparisons of features, but not performance. I don't think we actually need multithreaded interning, at least for clients and peers, since we should be getting all strings we'll encounter at initialization. The server might though, since it doesn't have an explicit registration phase (though we could also just not intern on the server).
Our data structures and function/method signatures make a lot of use of
Strings. This is good enough to work, but since essentially none of these strings are ever modified, we can probably save a lot on memory and performance by avoiding copies using&strand interned strings (though given how short most of these strings likely are, it's possible the overhead of the latter would be too heavy).Thinking about it a bit more, I think there is definitely some string interning we want to do, at the very least for onion addresses. This readme has some comparisons of features, but not performance. I don't think we actually need multithreaded interning, at least for clients and peers, since we should be getting all strings we'll encounter at initialization. The server might though, since it doesn't have an explicit registration phase (though we could also just not intern on the server).
Partially addressed by
67225eb8b5.