Faster on second try, but still very slow compared to the pharo run.

ping: twenty-five million, four hundred thousand elements.  Time: 0:05:10:48.25753825715344



five hours for 25mil vs 2.5 hours for 300+ mil.


Some things that are different in my squeak 6.0alpha image are:

1. it has 3 projects.
2. A Seaside Webserver was active listening for connection.


I am going to download a 5.3 vm and image and see what happens.










-----------------------------------------------------------------------------------

The thing is much slower on the first iteration on Squeak and it died on an invalid UTF8 character.

ping: one hundred five million, four hundred thousand elements.  Time: -0:11:18:22.899429

30097768


vs the three hundred thirty two million in the second pharo run.


VM stats after this run died with that UTF8 (and an image save) are:






uptime		14h 8m 47s	(runtime 12h 56m 50s, idletime 1h 11m 56s)


memory		166,723,584 bytes

old			157,771,552 bytes (94.6%)

young		7,190,528 bytes (4.3%)

used		132,113,272 bytes (79.2%)

free		27,185,008 bytes (16.3%)

GCs			141,172 (360.7 ms between GCs 330.2 ms runtime between GCs)

full		253 totalling 21,613 ms (0.05% runtime), avg 85.4 ms

marking		12,389 ms (57.3%) avg 49 ms,

compacting	9,224 ms (42.7%) avg 36.5 ms

scavenges	140,919 totalling 28,179 ms (0.06% runtime), avg 0.2 ms

tenures		150,988 (avg 1 tenures per scavenge)

Code compactions

119 totalling 91 ms (0% runtime), avg 0.8 ms

Since last view	140,880 (355 ms between GCs, 330 ms runtime between GCs)

uptime				50106.3 s, runtime 46493.8 s, idletime 3612.4 s

full					246 totalling 21,042 ms (0% runtime), avg 85.5 ms

scavenge				140,634 totalling 28,082 ms (0.1% runtime), avg 0.2 ms

tenures				52,604 (avg 0 tenures per scavenge)

code compactions	84 totalling 57 ms (0% runtime), avg 0.7 ms






This is on:


Image

-----

/home/wm/usr/src/smalltalk/XML/shared/Squeak6.0alpha-20582-64bit.image

Squeak6.0alpha

latest update: #20653

Current Change Set: SAXParser

Image format 68021 (64 bit)

Preferred bytecode set: SistaV1



Virtual Machine

---------------

/usr/local/lib/squeak/5.0-202110010850-64bit/squeak

Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3077]

Unix built on Oct  1 2021 13:12:54 Compiler: 4.2.1 Compatible Clang 3.8.0 (tags/RELEASE_380/final)

platform sources revision VM: 202110010850 wm at tinker:usr/src/smalltalk/tmp/oscogvm Date: Fri Oct 1 10:50:05 2021 CommitHash: 7ede113ff Plugins: 202110010850 wm at tinker:usr/src/smalltalk/tmp/oscogvm

CoInterpreter VMMaker.oscog-eem.3077 uuid: 8ad52133-62f2-4e1e-bf92-9b29ba104d62 Oct  1 2021

StackToRegisterMappingCogit VMMaker.oscog-eem.3077 uuid: 8ad52133-62f2-4e1e-bf92-9b29ba104d62 Oct  1 2021






I closed the image and re-opened it and it was lightning fast. the pharo took severl seconds...over 5 to save and close. opening is similarly slow.

I am on take two of the parse to see if it speeds up like the pharo second test run did.\

cordially

t

----------------------------------------------
oops, accidently hit send somehow.





I can inspect the SAXHandler  now...



(DocDemoSaxHandler on:('/home/wm/Downloads/bookstore.xml' asFileReference))  optimizeForLargeDocuments


gives me an inspector.

Before I kick this off on Squeak...here is the memory stuff from top menu->Extras->VM statistics

uptime		13m 40s	(runtime 1m 56s, idletime 11m 43s)

memory		183,500,800 bytes

old			174,548,768 bytes (95.1%)

young		7,190,528 bytes (3.9%)

used		142,214,448 bytes (77.5%)

free		34,639,056 bytes (18.9%)

GCs			292 (2810.9 ms between GCs 400.6 ms runtime between GCs)

full		7 totalling 571 ms (0.49% runtime), avg 81.6 ms

marking		326 ms (57.1%) avg 46.6 ms,

compacting	245 ms (42.9%) avg 35 ms

scavenges	285 totalling 97 ms (0.08% runtime), avg 0.3 ms

tenures		98,384 (avg 345 tenures per scavenge)

Code compactions

35 totalling 34 ms (0.029% runtime), avg 1 ms



I will kick it off now and see what happens.

cheers.

t







---- On Sat, 16 Oct 2021 16:17:29 -0400 gettimothy <mailto:gettimothy at zoho.com> wrote ----


Alright, I may have a FS fix. the *fx-core-converting already has an 'asReference' so I just add another method in the method-category that calls it...



In String 

create Method Category 'fs-core-converting'



add



asFileReference

   "Return an FSReference on disk"

   ^ self asReference
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211017/8df11d57/attachment.html>