fixes #19728; setLen slow when shrinking seq due to zero-filling of released area (#24683)

fixes #19728

don't zero-filling memory for "trivial types" without destructor in
refc. I tested locally with internal apis.

(cherry picked from commit b421d0f8ee)
This commit is contained in:
ringabout
2025-02-27 23:45:58 +08:00
committed by narimiran
parent 5394c6814b
commit fcf4f10c70
3 changed files with 40 additions and 4 deletions

View File

@@ -1925,6 +1925,13 @@ proc genArrayLen(p: BProc, e: PNode, d: var TLoc, op: TMagic) =
else: putIntoDest(p, d, e, rope(lengthOrd(p.config, typ)))
else: internalError(p.config, e.info, "genArrayLen()")
proc isTrivialTypesToSnippet(t: PType): Rope =
if containsGarbageCollectedRef(t) or
hasDestructor(t):
result = rope"NIM_FALSE"
else:
result = rope"NIM_TRUE"
proc genSetLengthSeq(p: BProc, e: PNode, d: var TLoc) =
if optSeqDestructors in p.config.globalOptions:
e[1] = makeAddr(e[1], p.module.idgen)
@@ -1945,10 +1952,11 @@ proc genSetLengthSeq(p: BProc, e: PNode, d: var TLoc) =
genTypeInfoV1(p.module, t.skipTypes(abstractInst), e.info)])
else:
const setLenPattern = "($3) #setLengthSeqV2($1, $4, $2)"
const setLenPattern = "($3) #setLengthSeqV2($1, $4, $2, $5)"
call.snippet = ropecg(p.module, setLenPattern, [
rdLoc(a), rdLoc(b), getTypeDesc(p.module, t),
genTypeInfoV1(p.module, t.skipTypes(abstractInst), e.info)])
genTypeInfoV1(p.module, t.skipTypes(abstractInst), e.info),
isTrivialTypesToSnippet(t.skipTypes(abstractInst)[0])])
genAssignment(p, a, call, {})
gcUsage(p.config, e)

View File

@@ -300,7 +300,7 @@ proc setLengthSeq(seq: PGenericSeq, elemSize, elemAlign, newLen: int): PGenericS
zeroMem(dataPointer(result, elemAlign, elemSize, newLen), (result.len-%newLen) *% elemSize)
result.len = newLen
proc setLengthSeqV2(s: PGenericSeq, typ: PNimType, newLen: int): PGenericSeq {.
proc setLengthSeqV2(s: PGenericSeq, typ: PNimType, newLen: int, isTrivial: bool): PGenericSeq {.
compilerRtl.} =
sysAssert typ.kind == tySequence, "setLengthSeqV2: type is not a seq"
if s == nil:
@@ -334,7 +334,8 @@ proc setLengthSeqV2(s: PGenericSeq, typ: PNimType, newLen: int): PGenericSeq {.
# presence of user defined destructors, the user will expect the cell to be
# "destroyed" thus creating the same problem. We can destroy the cell in the
# finalizer of the sequence, but this makes destruction non-deterministic.
zeroMem(dataPointer(result, elemAlign, elemSize, newLen), (result.len-%newLen) *% elemSize)
if not isTrivial: # optimization for trivial types
zeroMem(dataPointer(result, elemAlign, elemSize, newLen), (result.len-%newLen) *% elemSize)
else:
result = s
zeroMem(dataPointer(result, elemAlign, elemSize, result.len), (newLen-%result.len) *% elemSize)

View File

@@ -37,3 +37,30 @@ block: # bug #16771
a.foo b
doAssert a.n == 42
doAssert b.n == 1
block: # bug #24683
block:
var v = newSeq[int](100)
v[99]= 444
v.setLen(5)
v.setLen(100)
doAssert v[99] == 0
when not defined(js):
block:
var
x = @[1, 2, 3, 4, 45, 56, 67, 999, 88, 777]
x.setLen(0) # zero-fills 1mb of released data
type
TGenericSeq = object
len, reserved: int
PGenericSeq = ptr TGenericSeq
when defined(gcRefc):
cast[PGenericSeq](x).len = 10
else:
cast[ptr int](addr x)[] = 10
doAssert x == @[1, 2, 3, 4, 45, 56, 67, 999, 88, 777]