Newest at the top
| 2025-01-22 20:57:42 +0100 | <tomsmeding> | that's a + combining diaeresis, versus the pre-combined form |
| 2025-01-22 20:57:29 +0100 | <dminuoso> | And even if not, strided prefetchers will trigger (I dont know the assembly generated by compareByteArrays# however) |
| 2025-01-22 20:57:28 +0100 | <lambdabot> | False |
| 2025-01-22 20:57:26 +0100 | <tomsmeding> | > "\x61\x308" == "\xe4" |
| 2025-01-22 20:57:04 +0100 | <dminuoso> | Then memcmp is *definitely* faster. Depending on alignment it could a tight loop on a single cache line. |
| 2025-01-22 20:55:59 +0100 | <dminuoso> | https://hackage.haskell.org/package/text-2.1.2/docs/src/Data.Text.Array.html#compareInternal - so this ends up using memcmp or compareByteArrays# after all |
| 2025-01-22 20:55:28 +0100 | <dminuoso> | Guessimport qualified Data.Text.Array as A |
| 2025-01-22 20:55:20 +0100 | <dminuoso> | | lenA == lenB = A.equal arrA offA arrB offB lenA |
| 2025-01-22 20:54:56 +0100 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Client Quit) |
| 2025-01-22 20:54:51 +0100 | <dminuoso> | I dont.. know? |
| 2025-01-22 20:54:41 +0100 | <dminuoso> | But the question is very good actually |
| 2025-01-22 20:54:30 +0100 | <dminuoso> | Text contains unicode |
| 2025-01-22 20:54:27 +0100 | <tomsmeding> | but this is tangential to the point; is the answer to your original question answered by "lookup and ((lookup .) . map swap)"? |
| 2025-01-22 20:54:25 +0100 | <dminuoso> | tomsmeding: Uh, what about collation? |
| 2025-01-22 20:54:02 +0100 | <tomsmeding> | isn't equality on Text byte-equality, hence memcmp(), hence quite fast? |
| 2025-01-22 20:54:00 +0100 | <dminuoso> | The strings are all short (10-15ish) however |
| 2025-01-22 20:53:34 +0100 | <dminuoso> | The biggest cost will be equality on the Text probably. ;) |
| 2025-01-22 20:53:28 +0100 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en |
| 2025-01-22 20:52:45 +0100 | <Rembane> | Or maybe a vector? |
| 2025-01-22 20:52:40 +0100 | <tomsmeding> | but linear search is definitely quite fine, yes |
| 2025-01-22 20:52:30 +0100 | <tomsmeding> | a map might already be faster at that point, because it's not linear search in an array but in a linked list |
| 2025-01-22 20:52:21 +0100 | <dminuoso> | Linear search is probably faster in all cases. |
| 2025-01-22 20:52:04 +0100 | <dminuoso> | No bigger than 50 |
| 2025-01-22 20:52:03 +0100 | <tomsmeding> | complexity analysis is about the worst case. :) |
| 2025-01-22 20:51:54 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-22 20:51:43 +0100 | <tomsmeding> | what about the remaining 5%? |
| 2025-01-22 20:51:30 +0100 | <dminuoso> | Id have to do some statistical analysis, but I would say 95% of them have less than 15 elements. |
| 2025-01-22 20:51:25 +0100 | <tomsmeding> | ((lookup .) . map swap), rather |
| 2025-01-22 20:51:07 +0100 | <tomsmeding> | in which case, lookup and (lookup . map swap)? |
| 2025-01-22 20:50:55 +0100 | <tomsmeding> | unless the lists are small enough that you want to do linear search |
| 2025-01-22 20:50:44 +0100 | <tomsmeding> | dminuoso: I agree. But this does feel like it would benefit from a data structure that maintains the invariant |
| 2025-01-22 20:50:06 +0100 | <dminuoso> | tomsmeding: Not a big fan of depending on packages for a small isolated problem. |
| 2025-01-22 20:48:04 +0100 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2025-01-22 20:47:50 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-22 20:46:18 +0100 | agent314 | (~quassel@208.131.130.89) agent314 |
| 2025-01-22 20:42:53 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-22 20:41:28 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Remote host closed the connection) |
| 2025-01-22 20:41:18 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-01-22 20:37:08 +0100 | mulk | (~mulk@pd9514894.dip0.t-ipconnect.de) mulk |
| 2025-01-22 20:34:13 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) (Ping timeout: 248 seconds) |
| 2025-01-22 20:31:20 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-22 20:31:17 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90cc5a38f326993e22.dip0.t-ipconnect.de) acidjnk |
| 2025-01-22 20:30:38 +0100 | jocke-l | (jocke-l@a.x0.is) jocke-l |
| 2025-01-22 20:27:51 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-22 20:27:25 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-01-22 20:27:24 +0100 | jocke-l | (jocke-l@a.x0.is) (Quit: WeeChat 3.8) |
| 2025-01-22 20:25:09 +0100 | mulk | (~mulk@pd9514590.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-01-22 20:24:04 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2025-01-22 20:23:24 +0100 | benjamin | (~benjamin@2a03:4b80:a720:7ac0:7928:92d2:fc41:f8b4) (Ping timeout: 265 seconds) |
| 2025-01-22 20:22:17 +0100 | cy7 | (~yt@user/cysh) cysh |