summaryrefslogtreecommitdiff
path: root/sv.c
diff options
context:
space:
mode:
authorFather Chrysostomos <sprout@cpan.org>2014-10-01 16:17:52 -0700
committerFather Chrysostomos <sprout@cpan.org>2014-10-01 16:22:13 -0700
commitca0be6c0ab48a3aed9e55e641ec718654af7d550 (patch)
treedaae7732f1d31202678818daaade6df512546a47 /sv.c
parent8db6f480d9c44791b212bebb257534063f7fa9a8 (diff)
downloadperl-ca0be6c0ab48a3aed9e55e641ec718654af7d550.tar.gz
Correct and update sv.c’s string copy comments
Thanks to Dave Mitchell for pointing out my mistakes. Whether the rhs is copy-on-write already does not change whether we do the long-string-and-left-buffer-size check. The comments (added in 2ac0bcb35) were wrong. Also, update the comments for e8c6a474e, which added the big-buffer-on-the-right skip logic.
Diffstat (limited to 'sv.c')
-rw-r--r--sv.c23
1 files changed, 15 insertions, 8 deletions
diff --git a/sv.c b/sv.c
index 49bf8a0b59..5f29137440 100644
--- a/sv.c
+++ b/sv.c
@@ -4531,18 +4531,25 @@ Perl_sv_setsv_flags(pTHX_ SV *dstr, SV* sstr, const I32 flags)
* be allocated it is still not worth swiping PADTMPs for short
* strings, as the savings here are small.
*
- * If the rhs is already flagged as a copy-on-write string and COW
- * is possible here, we use copy-on-write and make both SVs share
- * the string buffer.
- *
- * If the rhs is not flagged as copy-on-write, then we see whether
- * it is worth upgrading it to such. If the lhs already has a buf-
+ * If swiping is not an option, then we see whether it is
+ * worth using copy-on-write. If the lhs already has a buf-
* fer big enough and the string is short, we skip it and fall back
* to method 3, since memcpy is faster for short strings than the
* later bookkeeping overhead that copy-on-write entails.
+
+ * If the rhs is not a copy-on-write string yet, then we also
+ * consider whether the buffer is too large relative to the string
+ * it holds. Some operations such as readline allocate a large
+ * buffer in the expectation of reusing it. But turning such into
+ * a COW buffer is counter-productive because it increases memory
+ * usage by making readline allocate a new large buffer the sec-
+ * ond time round. So, if the buffer is too large, again, we use
+ * method 3 (copy).
*
- * If there is no buffer on the left, or the buffer is too small,
- * then we use copy-on-write.
+ * Finally, if there is no buffer on the left, or the buffer is too
+ * small, then we use copy-on-write and make both SVs share the
+ * string buffer.
+ *
*/
/* Whichever path we take through the next code, we want this true,