[06:28:57] And here is me trying to get things under 10000! But for sure everything underneath adds up. (re @Al: Well… the benefits compound. Z18998 often had performance in the hundreds of ms. Now it’s down to around 50 and I’m hopeful we’l...) [10:33:56] To that end, something to think about is named key accessors. I’ve just implemented an unfriendly equivalent of Z14399 (Z32058) using just Z803. For comparison (v2 measures before promotion): [10:33:56] Z14399: [10:33:58] 44, 44, 35 (duration in ms) [10:33:59] 47, 111, 37 (~CPU in ms) [10:34:01] Z33058: [10:34:02] 19, 29, 12 (duration in ms) [10:34:04] 15, 44, 14 (~CPU in ms) [10:34:05] Two other structural factors influence these results. The conditions are not ANDed and the strings are tested before the language tags. In case of inequality, the comparison order matters, but it’s not clear to what extent. The third test-case is the one for same language, different text. [10:34:07] Following promotion by WikiLambda System, the current figures for the previous composition are wildly different (worse), which is something we should keep an eye on in case the wrong implementation gets preferred. The new implementation’s performance now: [10:34:08] (27, ~27), (21, ~30), (14, ~13) (re @u99of9: And here is me trying to get things under 10000! But for sure everything underneath adds up.) [11:00:57] Z14399 Z33058 [11:02:47] Z32058 [11:02:58] Z14399 [11:16:36] The second ZID is 1000 ahead of existing ZIDs (re @u99of9: Z14399 Z33058) [11:20:51] Only in the test-case results. In Try this… the other implementations are below 100. I can’t explain the difference 🤷‍♂️ (re @u99of9: The second ZID is 1000 ahead of existing ZIDs) [11:22:17] Oh, sorry, I was explaining why the bot didn't link the ZIDs. There was a typo in the second one. (re @Al: Only in the test-case results. In Try this… the other implementations are below 100. I can’t explain the difference 🤷‍♂️) [11:24:19] Oh, my mistake (x2)… But one incorrect ZID shouldn’t block the correct ones 🤷‍♂️ (re @u99of9: Oh, sorry, I was explaining why the bot didn't link the ZIDs. There was a typo in the second one.) [15:21:43] On another positive performance note, I was (just) able to apply a wide filter to the complete set of statements from Q30 and view the results (carefully… eventually) on my iPhone (Safari browser). For the stout of heart, these are the performance statistics: [15:21:44] *Duration [15:21:46] *9996 ms [15:21:47] Orchestration: [15:21:49] Duration: 9996 ms [15:21:50] Evaluation: [15:21:52] Duration: 8093 ms [15:21:53] *CPU usage [15:21:55] *2497 ms [15:21:56] Orchestration: 2295.599 ms [15:21:58] Evaluation: 201.773 ms [15:21:59] Execution: 32610 μs [15:22:01] *Memory usage [15:22:02] *526.0 MiB [15:22:04] Orchestration: 351.93 MiB [15:22:05] Evaluation: 172.91 MiB [15:22:07] Execution: 1.2 MiB [15:22:08] I think the Evaluation resource utilisation is largely attributable to converting a JavaScript Array result back into a typed list. [15:22:10] (The “wide” filter was no filter at all, which leaves (?) 1686 statements. The result was mediated via Echo, which is what I was checking out at the time: [15:22:11] filter statements by property type (https://www.wikifunctions.org/view/en/Z28548) (statements from Wikidata item (https://www.wikifunctions.org/view/en/Z22220) (United States (https://www.wikidata.org/wiki/Q30)), Typed list (https://www.wikifunctions.org/view/en/Z881) (Wikidata property reference (https://www.wikifunctions.org/view/en/Z6092))) [15:22:13] This should be equivalent to this much more efficient call (https [15:22:13] //www.wikifunctions.org/view/en/Z22220?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z22220%22%2C%22Z22220K1%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z30120%22%2C%22Z30120K1%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q30%22%7D%2C%22Z30120K2%22%3A%5B%22Z6030%22%2C%22Z6036%22%5D%2C%22Z30120K3%22%3 [15:22:14] A%5B%22Z60%22%5D%2C%22Z30120K4%22%3A%5B%22Z6092%22%5D%7D%7D) [15:22:16] with this performance: [15:22:17] *Duration [15:22:20] *1242 ms [15:22:22] *CPU usage [15:22:24] *772.6 ms [15:22:26] *Memory usage [15:22:28] *303.7 MiB) [18:46:01] Hi folks, Thanks for raising this question and apologies for the slow response! Yeah, I had mixed feelings about doing it this way. It was desired to get this out quickly, and the thinking was (1) it might be sufficient to document the small set of allowed string values in the Z6039 type description (and mention that in Z6839), and (2) it's a fairly specialized [18:46:01] function where t [18:46:02] he function callers are likely to be experienced and thus might not care about getting explicit guidance when specifying a value, (3) there is not likely to be another use for a new enum type for these 9 Wikidata project types, and (4) maybe we should defer this until T405810 has been done (as mentioned above). However, this thinking does seem weak, and if there is a [18:46:02] consensus t [18:46:04] hat this should be changed, I'd be happy to do that. Happy to hear further feedback here and also, I'll take a poll within the team. (re @Al: Or it could just be an ordinary enumeration… but it would be good to pick Wikipedia rather than typing "wiki". I suppose we coul...) [18:46:39] Created T420122. (re @David: Hi folks, Thanks for raising this question and apologies for the slow response! Yeah, I had mixed feelings about doing it this ...) [18:49:35] Yes, I’m not entirely convinced, but I’d almost prefer a named function per allowed value 🤷‍♂️ (re @David: Hi folks, Thanks for raising this question and apologies for the slow response! Yeah, I had mixed feelings about doing it this ...)