00:30:53 <Resgate[m]> Grupo Monero no Xmpp
00:30:53 <Resgate[m]> Mais leve que a rede Matrix, e muito mais fluido 
00:30:53 <Resgate[m]> xmpp:monero-brasil---sem-ban⊙cci?join
00:52:46 <plowsof11> 9~ hours to create many addresses . now 9~ minutes thanks to moneromoo https://github.com/monero-project/monero/pull/5370#issuecomment-1436154807 
07:37:18 <moneromooo> You're welcome :)
08:32:54 <geonic> damn
09:04:41 <hyc> sounds like unordered map really sucks
09:05:06 <hyc> is flat_map ordered?
09:05:17 <sech1> sucks how?
09:06:05 <hyc> looking at the perf diff noted above
09:06:11 <sech1> it's O(1). Yes, actual default implementations may be slow or waste memory, but there are better implementations
09:06:16 <sech1> like the one I use in p2pool
09:07:07 <sech1> 9 hours down to 9 minutes sounds more like poor hashing function, so it's not O(1) anymore
09:08:28 <hyc> indeed
09:08:52 <sech1> flat_map probably just takes better precautions when hashing user data
09:09:29 <hyc> is it ordered? since they're taking the trouble to sort to check for duplicates
09:09:44 <hyc> seems odd to me that the map itself can't warn you of duplicates
09:09:48 <sech1> now wait, it's not a hash map
09:09:50 <sech1> https://www.boost.org/doc/libs/1_70_0/doc/html/boost/container/flat_map.html
09:10:01 <sech1> Complexity: Logarithmic.
09:10:38 <hyc> ah yes, ordered sequence container
09:10:51 <hyc> so, some kind of tree, not a hash
09:11:51 <hyc> "random access iterators" - the word "iterator" was always a mistake. these are cursors.
09:11:57 <hyc> C++ is such a stupid language...
09:12:09 <sech1> ordered sequence container that uses a vector to store elements, interesting
09:12:18 <sech1> so it takes advantage of CPU caching for faster access
09:12:25 <sech1> and has random access iterators
09:13:00 <sech1> so if O(logN) container beats O(1) container, it's definitely a problem with hash function
09:13:53 <sech1> beats by 60x, lol
09:20:25 <hyc> simple stuff we learned in data structures classes in the 1980s. seems like all forgotten by the current generation
09:23:22 <sech1> it's a different problem here though: std::vector<std::vector<std::string>> m_subaddress_labels;
09:23:49 <sech1> current code resizes the vertor every time you call wallet2::add_subaddress(), so it's O(N^2)
09:23:58 <sech1> if you add addresses one by one
09:24:14 <sech1> https://github.com/monero-project/monero/pull/5370/commits/cc379879e755315953e47e3bfb69b464cf634840 fixes it so vector gets resized only once
09:32:37 <hyc> so, it's got nothing to do with the map type at all
10:40:52 <one-horse-wagon[> Seraphis meeting today at 18:00 UTC in Matrix room--No Wallet Left Behind.
12:15:44 <moneromooo> I had a second patch to use a map for non-empty labels, didn't help save/open but I did not test insert...
21:04:15 <UkoeHB> tevador: here is my idea for the eclib abstraction https://github.com/UkoeHB/monero/commit/5b9b030b95aae0260b751093041c956c4d139bfe however it has a linker error in the unit test (the eclib::utils::util_func()) that I am stumped on. What I'm trying to do is instantiate the utils functions inside the eclib_interface.cpp file so the linker can connect with those. I don't want to include the full eclib_utils template everywhere 
21:04:15 <UkoeHB> since that would be a compiletime horror.
21:08:14 <UkoeHB> the overall goal is that you can switch this statement `using eclib = crypto::eclib_test;` and everything that uses `eclib::` will just continue to work nicely
21:35:53 <tevador> UkoeHB: I think you need to put "template<>" in front of "eclib_test::core_func" in eclib_test.cpp
21:39:41 <UkoeHB> tevador: the core_func() works fine, its the util_func() that doesn't link
21:42:37 <sech1> you can't just include a template in a single file, other files won't see it and won't be able to instantiate it
21:43:07 <sech1> if you want to do this, you have to declare each instantiation of this template in a header
21:43:20 <sech1> then these instantiations will link
21:44:01 <defeatoverseer[m> TLDR - Need a quantifiable counter measure for preventing the Overseer Attack. Will be paying for this research. Want to get started sooner rather than later.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/14dad6dedc8b46b2583e49d97e499997ae31f7b2>)
21:44:02 <tevador> it doesn't need to be in the header, it can be explicitly instantiated in one cpp file
21:44:21 <sech1> I mean, yes
21:44:23 <UkoeHB> sech1: I put a template declaration in a header file
21:44:34 <sech1> template declaration in a header, and explicit instantiaion in some cpp
21:44:38 <UkoeHB> and trying to instantiate the bodies in one cpp
21:47:25 <sech1> no, it doesn't work like this. You have to explicitly instantiate it as a declaration in this cpp
21:47:27 <sech1> https://stackoverflow.com/questions/115703/storing-c-template-function-definitions-in-a-cpp-file
21:47:30 <tevador> it still needs template<> void eclib_utils<eclib_test>::util_func(...); somewhere
21:48:28 <sech1> if you don't do it, compiler makes it internal linkage, or even just inlines the code
21:52:56 <UkoeHB> ok looks like I needed to add `template struct eclib_utils<eclib_test>;` to the eclib_interface.cpp file