From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Map iteration and modification
Date: Sat, 30 Dec 2023 00:29:07 -0600 [thread overview]
Message-ID: <umoda6$16pk8$1@dont-email.me> (raw)
In-Reply-To: ummj1i$e64$1@rasp.pasdenom.info
"DrPi" <314@drpi.fr> wrote in message
news:ummj1i$e64$1@rasp.pasdenom.info...
... (Example eliminated)
> That's what I did but I saved the keys (String) instead of the cursors.
> Does it make a difference ? Performance maybe ?
It certainly will make a performance difference; whether that difference is
significant of course depends on the implementation. There's two parts to it
(one of which I thought of yesterday and the other which I forgot):
(1) The cost of storing keys vs. storing cursors. Cursors are going to be
implemented as small record types (cannonically, they are two pointers, one
to the enclosing container and one to the specific node/element). A key can
be most anything, and storing that can be more costly.
(2) The cost of looking up a key. A map is a set of nodes, and there
needs to be some operation to associate a key with the correct node. Those
operations take some time, of course: for a hashed map, the key has to be
hashed and then some sort of lookup performed. Whereas a cursor generally
contains an indication of the node, so the access is more direct.
For a lot of applications, this difference won't matter enough to be
significant. But I'd probably lean toward using cursors for this sort of job
as that would minimize performance problems down the line. (Of course, if
the container gets modified after you save the cursors, then they could
become dangling, which is a problem of it's own. If that's a possibility,
saving the keys is better.)
Randy.
next prev parent reply other threads:[~2023-12-30 6:29 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 13:53 Map iteration and modification DrPi
2023-12-28 13:59 ` DrPi
2023-12-28 16:06 ` Dmitry A. Kazakov
2023-12-28 17:57 ` DrPi
2023-12-29 3:20 ` Randy Brukardt
2023-12-29 9:51 ` Dmitry A. Kazakov
2023-12-29 15:03 ` G.B.
2023-12-29 16:52 ` Dmitry A. Kazakov
2024-01-01 19:27 ` G.B.
2024-01-01 20:55 ` Dmitry A. Kazakov
2024-01-02 16:40 ` G.B.
2024-01-02 20:57 ` Dmitry A. Kazakov
2024-01-03 3:22 ` Randy Brukardt
2024-01-03 4:05 ` moi
2023-12-30 7:21 ` Randy Brukardt
2023-12-30 11:07 ` Dmitry A. Kazakov
2024-01-03 3:15 ` Randy Brukardt
2024-01-03 10:04 ` Dmitry A. Kazakov
2024-01-04 4:07 ` Randy Brukardt
2024-01-04 11:28 ` Dmitry A. Kazakov
2024-01-05 2:00 ` Randy Brukardt
2024-01-05 9:26 ` Simon Wright
2024-01-05 11:51 ` Dmitry A. Kazakov
2024-01-06 7:25 ` Randy Brukardt
2024-01-07 15:06 ` Jeffrey R.Carter
2024-01-09 4:46 ` Randy Brukardt
2024-01-09 5:56 ` when-clauses (was Re: Map iteration and modification) Lawrence D'Oliveiro
2024-01-09 9:43 ` Map iteration and modification Jeffrey R.Carter
2024-04-17 10:12 ` Cóilín Nioclás Pól Glostéir
2024-01-06 2:54 ` “Usability” (was Re: Map iteration and modification) Lawrence D'Oliveiro
2024-01-06 7:03 ` "Usability" " Randy Brukardt
2024-01-06 8:14 ` Niklas Holsti
2024-01-06 23:41 ` Lawrence D'Oliveiro
2024-01-07 1:21 ` J-P. Rosen
2024-01-09 15:19 ` Bill Findlay
2024-01-09 20:30 ` Lawrence D'Oliveiro
2023-12-29 3:08 ` Map iteration and modification Randy Brukardt
2023-12-29 13:53 ` DrPi
2023-12-30 6:29 ` Randy Brukardt [this message]
2023-12-31 13:56 ` DrPi
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox