Sender | Message | Time |
---|---|---|
4 Nov 2023 | ||
🙌 | 08:58:19 | |
7 Nov 2023 | ||
hi all do we have some common collection of hepers like this? | 12:32:24 | |
* hi all do we have some common collection of helpers somewhere like this? | 12:32:37 | |
g_list_find() ? | 17:37:45 | |
uppsss, i found only g_list_find_custom, but yeah, its a valid one too apart from that, any common place to put similar extensions? | 18:20:40 | |
(BTW: i guess g_list_find also uses an an O(N*M) algorithm) | 18:30:30 | |
It uses an O(M) the N comes from the stats foreach call. | 19:06:54 | |
So yes, this one is the same. But the previous algorithm was O(N), while the new one is worse. | 19:08:17 | |
do you mean using g_list_find() ? | 19:51:20 | |
You iterate all the stats (N) and then within each callback iterate the other list (M) | 19:52:17 | |
g_list_find() iterates that too. So regardless if you use the custom coded function or g_list_find() the complexity is the same. | 19:53:01 | |
Could you solve it so it's not worse than linear? | 19:55:50 | |
E.g. just iterate one of the lists. If I am not missing something it should be doable. | 19:56:41 | |
of course, they are the same, i just replaced it as it has an already implemented "native" pair, so a custom one was not needed at all i asked it because you mentioned that "the new one is worst", I asked about if the "g_list_find()" was the worst (as i assumed they are the same) | 20:53:19 | |
* of course, they are the same, i just replaced it as it had an already implemented "native" pair, so a custom one was not needed at all i asked it because you mentioned that "the new one is worst", I asked about if the "g_list_find()" was the worst (as i assumed they are the same) | 21:00:59 | |
* of course, they are the same, i just replaced it as it had an already implemented "native" pair, so a custom one was not needed at all i asked it because you mentioned that "the new one is worst", I asked about if the "g_list_find()" was the worst (as i assumed they are the same, that is why i replaced the custom one with g_list_find()) | 21:01:43 | |
I just wanted to use the existing, same code, and logic to test if a given StatsCounterItem should be reset or not_reset_counter_if_needed needs both a StatsCluster and a StatsCounterItem to make this decisionin the query case we do have only the StatsCounterItem sgetting the StatsCluster for each of them leads always to an iteration like the actual "slow" onei cannot really see now a better option, and how can this be solved with "one iteration" could you please give me some hints about how the stats_cluster_get_type_name(sc, type) call can be fed by the correct StatsCluster if we have only the StatsCounterItem a.k.a. how can i get more quickly the StatsCluster of a given StatsCounterItem | 21:11:52 | |
9 Nov 2023 | ||
16:13:28 | ||
I'm the guy whom you saw at the Observability meetup in Budapest last September 🙂 | 18:44:26 | |
18:44:26 | ||
* I'm the guy who you saw at the Observability meetup in Budapest last September 🙂 | 18:44:49 | |
13 Nov 2023 | ||
13:56:25 | ||
18:03:19 | ||
19:12:25 | ||
16 Nov 2023 | ||
17:46:53 | ||
21 Nov 2023 | ||
19:07:00 | ||
pwd | 21:28:46 | |
24 Nov 2023 | ||
what was the end result of this? i'd like to use the same astyle config that the OSE repo contains, but currently it works against the accepted style could you please provide a valid .astylerc file (that works with the latest astyle version)? | 12:29:15 | |
I think we could use comment blocks for logical separation in the instance above | 13:02:10 | |
14:24:47 |