Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
[Coke] well done, nine. 05:06
ugexe MVM_file_chown takes int arguments, but i think they are supposed to be unsigned. see github.com/nodejs/node-v0.x-archiv...dd33d82d37 19:28
MasterDuke yep, nice catch 21:08
i should be able to fix that today or tomorrow 21:09
lizmat so, it looks like if you create a *large* string (such as by slurping a 4MB file) 21:56
lizmat and you take a 1 char substring of that, it will keep the large string in memory because of the substring 21:57
is there a way to disassociate a substring from such a large string ?
nqp::indexingoptimized doesn't seem to cut it 22:01
japhb lizmat: Incredibly ugly hack, but ... encode the substring into a buffer, drop all references to the original string or the substring, decode the buffer back into a new string? 22:09
lizmat something like:
nqp::strtocodes($string, nqp::const::NORMALIZE_NFC, my int32 @ords);
nqp::strfromcodes(@ords)
??
nine Or just $substring.encode.decode 22:12
lizmat if that would work, it wouldn't matter how big the original string was, right? 22:15
basic code: 22:26
use Telemetry;
for ^100 {
my $a = substantiate($io.slurp.substr(0,1));
}
END say T<max-rss>;
where $io is either a 4 byte or a 4MB file
japhb lizmat: Right, shouldn't matter at all. 22:28
lizmat it does :-(
so that would make it not work
japhb Of course, just because the original string is now garbage, doesn't mean it has been collected .... 22:29
lizmat reason I'm asking is IRC log parsing for instance
hmmm
lizmat nqp::force_gc appears to make a difference... 22:31
for ^100 { 22:32
my $a = $io.slurp.substr(0,1);
nqp::force_gc;
}
actually, hiving: 22:39
start { loop { sleep .1; nqp::force_gc } }
running, seems to have a very beneficial effect on memory usage, and no effect on CPU usage 22:40
*having 22:42
putting a "nqp::force_gc() unless nqp::mod_i(++$force_gc,100);" into the ThreadPoolScheduler supervisor loop 22:58
has a similar positive effect on memory usage of the above code 23:02
lizmat sleeps on it 23:04