Re^4: RE on lines read from in-memory scalar is very slow

I had forgotten about reflecting writes to the string, that would certainly nix the idea of using copy-on-write substrings.

Does the regex engine *always* make a full clone of the target? Can't that itself be a copy-on-write? Maybe only if the match target was already copy-on-write?

Maybe what I'm suggesting here is an optimization for sv_gets that kicks in when

The file handle is backed by a scalar
The scalar already has the CoW flag set on it, or scalar itself has a refcount of 1 (meaning that the app no longer has access to modify it)
The file handle is read-only,
The file handle has only simple layers on it like the default or :raw (maybe extend to support :utf8)

then short-circuit around the regular behavior and return a CoW substring? As I describe it, its sounding like too much effort, but I'm still curious if it would work.

Comment on Re^4: RE on lines read from in-memory scalar is very slow

Replies are listed 'Best First'.
Re^5: RE on lines read from in-memory scalar is very slow by tonyc (Friar) on Feb 21, 2024 at 00:01 UTC
The regex engine currently always makes a CoW copy (ie doesn't copy the string itself) of the matched string. There's no CoW substrings - perl's PVs are stored with a trailing NUL so they're useful as a C-style string, and perl itself and XS code depends on that, so I don't think it can be implemented in any case.	[reply]
Re^6: RE on lines read from in-memory scalar is very slow by NERDVANA (Priest) on Feb 21, 2024 at 00:10 UTC
Ah-ha! Well that helps improve my understanding for future attempts at optimizing my scripts.	[reply]