binary1248/SFGUI — comment on commit 4929df2ae58abf692d14407280d568008efee988
File: include/SFGUI/Signal.hpp line 54
By TankOs:

Associative containers are not only meant to access elements *fast* by key, they also give you an idea of the underlying design. If it's time-critical, I agree to change something not harmonizing with design, if it's for 1-2 extra FPS in benchmarking situations, it's just not worth it (even if you've got 10 of such "optimizable" places). That's the only reason I ask for numbers. I want to know if it's *crucial*.

Remember I did the comparision between an iterator loop for std::list vs. std::vector (direct index). With 1,000,000 elements the list needed 47 ms, vector 7 ms on my machine. It seems "OMG" for the benchmark, but in real-world situations, it's absolutely useless. If you're searching a std::list every frame for something, you probably want to rethink if you really want a std::list.

Also remember *what* the container (the std::map one) is used for: Signals. There are only a handful of signals that get called every frame (like OnExpose) for every widget. Even with 1,000 widgets your (even old!) CPU would laugh at you while staying in the std::map iterations for some micro seconds. Like said, if you have numbers that show it's *really slow*, I might get convinced, but up to now I think it's the good ol' premature optimization or optimization for fun. ;-)

Caching size() and doing a vector due to assumptions how often and when stuff gets called (imagine someone disconnects signals a lot, which would fire some O(n) searches) may give you some performance, but in the end, you have a shitload of possible error resources and a higher degree of maintaining your stuff right (this especially includes the fact others may be working with the library, and it's highly unusual to keep container sizes cached somewhere, which will lead to confusion for sure).