Slow???

2023-08-17 Thread ToddAndMargo via perl6-users

Hi All

Fedora 38

$ raku -v
Welcome to Rakudo™ v2023.06.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2023.06.


Has the compiler gotten really, really, really
slow lately?

What normally takes 8 seconds is now dragging on
for minutes,

$ raku -c GetUpdates.pl6

Perplexed,
-T


Found the source of the drag, but it is still slow.

 #`(
 Aug 08, 2023
 
 href="https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/continuous/dccontinuousaug2023.html\
  #dccontinuousaugtwentytwentythree" 
disablelinktracking="false">\

  DC Aug 2023 (23.003.20269)
 
 Continuous
 
 Latest Release: This update provides new features, 
security mitigations, feature enhancements, and bug fixes.

  }

#`( should have been #`{



--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

On 4/28/19 4:26 PM, ToddAndMargo via perl6-users wrote:

On 4/20/19 8:58 PM, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


Follow up:  Figured it out.  Well, ALMOST.  (Watch the weasel word.)


First I had to fix up zef.  I posted it on another thread, but
I will repost it here too:


On 4/28/19 4:09 PM, ToddAndMargo via perl6-users wrote:   > Well now, 
too many cooks spoil the stew.


I did a full `dnf remove rakudo rakudo-zef`

Then every "zef" entry (~.zif, /root/.zef, etc.) on my hard
drive and erased it.

And, every perl6 directory (opt, lib64, ~.perl6, etc.)
and erased is too.

Then reinstalled rakudo and rakudo-zef.

Now zef is working right.

Apparently, I hade too many different types/version
of installs out there and everything was getting all
mixed up. 




And low and behold, "Stage Parse" went
from 13 seconds to 6 seconds:

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :   5.727
Stage syntaxcheck:   0.000
Stage ast    :   0.000
Stage optimize   :   0.369
Stage mast   :   1.210
Stage mbc    :   0.021
Stage moar   :   0.000
GetUpdates.pl6
Mozilla Mirror 
Debug is OFF


Still about 5 seconds too slow, but a vast improvement.

Thanks to everyone for all the tips and help!

-T



[18:18]  ToddAndMargo: stage parse is where the
compiler parses your source code into an AST (abstract syntax
tree) before turning the AST into bytecode. it uses rakudo's
grammar engine, which isn't very optimized yet


--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

On 4/20/19 8:58 PM, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


Follow up:  Figured it out.  Well, ALMOST.  (Watch the weasel word.)


First I had to fix up zef.  I posted it on another thread, but
I will repost it here too:


On 4/28/19 4:09 PM, ToddAndMargo via perl6-users wrote:   > Well now, 
too many cooks spoil the stew.


I did a full `dnf remove rakudo rakudo-zef`

Then every "zef" entry (~.zif, /root/.zef, etc.) on my hard
drive and erased it.

And, every perl6 directory (opt, lib64, ~.perl6, etc.)
and erased is too.

Then reinstalled rakudo and rakudo-zef.

Now zef is working right.

Apparently, I hade too many different types/version
of installs out there and everything was getting all
mixed up. 




And low and behold, "Stage Parse" went
from 13 seconds to 6 seconds:

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :   5.727
Stage syntaxcheck:   0.000
Stage ast:   0.000
Stage optimize   :   0.369
Stage mast   :   1.210
Stage mbc:   0.021
Stage moar   :   0.000
GetUpdates.pl6
Mozilla Mirror 
Debug is OFF


Still about 5 seconds too slow, but a vast improvement.

Thanks to everyone for all the tips and help!

-T


Re: Why so slow

2019-04-28 Thread Joseph Brenner
Brad Gilbert  wrote:
> For one it has the following line:
>
> use lib 'lib';
>
> That is going to slow everything down if you have anything in the
> `lib` directory.
> The more things in that directory, the slower it will get.


I've been seeing some pretty slow perl6 one-line invocations,
where something like this might take 10 secs:

   perl6 -e'say "yellow"'

This evidently has to do with this perl alias I use that loads a module:

   alias perl6='perl6 -Mmethod-menu'

I do have a number of locations in my $PERL6LIB, and while they
could certainly be trimmed down, the sheer number of them don't
seem excessive to me (certainly not compared to my PERL5LIB):


  echo $PERL6LIB | tr ",", "\n"
  /home/doom/End/Cave/IntrospectP6/Wall/Object-Examine/lib/
  /home/doom/End/Cave/IntrospectP6/Wall/Augment-Util/lib
  /home/doom/End/Cave/IntrospectP6/Wall/Symbol-Scan/lib
  /home/doom/End/Cave/IntrospectP6/Wall/method-menu/lib
  /home/doom/End/Cave/IntrospectP6/Wall/perl6-object-examine/lib/
  /home/doom/End/Cave/IntrospectP6/Wall/perl6-augment-util/lib
  /home/doom/End/Cave/IntrospectP6/Wall/perl6-symbol-scan/lib
  /home/doom/End/Cave/IntrospectP6/Wall/perl6-method-menu/lib
  /home/doom/End/Cave/Perl6/lib
  /home/doom/End/Cave/Eye/lib/perl6
  /home/doom/lib/perl6
  /home/doom/End/Sys/Perl6/perl6-Perl6-Tidy-master/lib
  /home/doom/End/Sys/Perl6/perl6-Perl6-Parser-master/lib
  /home/doom/End/Sys/Perl6/p6-JSON-Pretty-master/lib


Cutting those locations down to just three (most of them were
empty, anyway):

  echo $PERL6LIB | tr ",", "\n"
  /home/doom/End/Cave/Perl6/lib
  /home/doom/End/Cave/Eye/lib/perl6
  /home/doom/lib/perl6

Gets you a roughly 6x speed-up:

  time perl6 -e'say "Sy..."'
  Sy...

  real  0m1.685s


Re: Why so slow

2019-04-28 Thread Joseph Brenner
ToddAndMargo via perl6-users  wrote:
>  David Christensen wrote:
>> We discussed this at our San Francisco Perl Mongers meeting today:
>
> Any Perl 5 guys there?  And did they get "grouchy" with you
> for using Perl 6?

We've been doing an "Informal Perl6 Study Group" over at the Oakland
Museum cafe every weekend.  The idea is actually to talk about perl6
stuff, though pretty often we actually veer off into perl5, R, etc.
And I don't usually get grumpy about it myself,  though I'm a pretty
grumpy character by nature.


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

On 4/28/19 2:21 AM, Timo Paulssen wrote:
the strace command ended up only tracing the shell script "perl6", which 
very quickly execs moar, at which point strace considers its job done. 
there was barely any output at all for that reason.


fortunately we can just add -f to the strace command so that it follows 
processes as they are spawned.


does /home/linuxutil have many files and folders in it?


There are 275 files in it.  Basically all my perl 5, perl 6
and bash scripts, along with a ton of supporting file (tmp, etc.).
I will vpaste an ls if you need it,



was the output from RAKUDO_MODULE_DEBUG going smoothly, or were there 
any points where it did any very long pauses?


Could not tell.  I sent the output to a file so I could vpaste it

it does look a little like some of your individual modules have their 
own "use lib" commands in them, but i'm not exactly sure how it 
influences precompilation and such.


They do.

Is there another way to get Perl to looks for modules in other directories?


I am out of business for the time being until I get that zef error fixed

Thank you for all the help with this!

-T


Re: Why so slow

2019-04-28 Thread Timo Paulssen
the strace command ended up only tracing the shell script "perl6", which 
very quickly execs moar, at which point strace considers its job done. 
there was barely any output at all for that reason.


fortunately we can just add -f to the strace command so that it follows 
processes as they are spawned.


does /home/linuxutil have many files and folders in it?

was the output from RAKUDO_MODULE_DEBUG going smoothly, or were there 
any points where it did any very long pauses?


it does look a little like some of your individual modules have their 
own "use lib" commands in them, but i'm not exactly sure how it 
influences precompilation and such.


On 28/04/2019 09:21, ToddAndMargo via perl6-users wrote:




Hi Timo,

This tell you anything?

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :  13.150
Stage syntaxcheck:   0.000
Stage ast    :   0.000
Stage optimize   :   0.351
Stage mast   :   1.133
Stage mbc    :   0.019
Stage moar   :   0.000

GetUpdates.pl6  <-- my program starts here
Mozilla Mirror 
Debug is OFF


The "Stage parse : 13.150" is eating me alive!

-T


On 4/28/19 12:01 AM, Timo Paulssen wrote:> Please give this a try:
>
>  env RAKUDO_MODULE_DEBUG=1 perl6 GetUpdates.pl6
>
> and tell me if any of the lines it spits out takes considerable amounts
> of time before the next one shows up.
>
> Then, you can also
>
>  strace -e stat perl6 GetUpdates.pl6
>
> to see if it's going through a whole load of files.
>
> without the "-e stat" you will get a whole lot more output, but it'll
> tell you pretty much everything that it's asking the kernel to do.
> Pasting that whole file could be a privacy concern, especially if it
> iterates your entire home directory, which is still my working 
hypothesis.

>
> HTH
>    - Timo
>

My home directory is pretty small, except for .wine.
All the good stuff is on my network shares to share
with my numerous VM's


$ env RAKUDO_MODULE_DEBUG=1 perl6 GetUpdates.pl6 > GetUpdates.debug 2>&1
http://vpaste.net/xmwcd


$ strace -e stat perl6 GetUpdates.pl6 > GetUpdates.debug 2>&1
http://vpaste.net/8ekeI


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

On 4/27/19 10:40 PM, David Christensen wrote:

We discussed this at our San Francisco Perl Mongers meeting today:



Any Perl 5 guys there?  And did they get "grouchy" with you
for using Perl 6?  Did they call Perl 6 "Java" by any chance?

Chuckle.


Re: Why so slow

2019-04-28 Thread David Christensen

On 4/27/19 10:40 PM, David Christensen wrote:

I suggested that he install the official package:

https://rakudo.org/files



The Rakudo site is degraded:

"Currently, rakudo.org is being served from a back-up server that 
doesn't have the download files."



I had previously downloaded installers for Debian and for macOS:

2019-04-28 00:14:14 dpchrist@tinkywinky ~/samba-dpchrist/Downloads/p/perl6
$ ls -1hs rakudo-*
 11M rakudo-pkg-Debian9_2019.03.1-01_amd64.deb
6.0K rakudo-pkg-Debian9_2019.03.1-01_amd64.deb.sha1
 25M rakudo-star-2019.03.dmg


If anyone needs them, send me an e-mail off list.


David


Re: Why so slow

2019-04-28 Thread David Christensen

On 4/28/19 12:07 AM, Timo Paulssen wrote:

I'm writing a program called moarperf, which is a local web app written in Cro 
that doesn't touch the network outside of loopback. It just has to build its 
JavaScript blobs once by downloading like a brazillion libraries from npm.


That should be useful.



Also, comma complete comes with support for profiling, which also doesn't need 
a live net connection.


https://commaide.com/



Finally, I think at least Debian patches the profiler html app to point at an 
angularjs downloaded from Debian repositories. It's quite feasible to have an 
env var for nqp/rakudo that changes the path to the js libraries to something 
local.


I use Mozilla Firefox with the NoScript plug-in -- that's how I saw that 
JavaScript is required.  The profile pages seem to work on Debian at the 
present time if I do nothing (JavaScript is cached?), but requires 
JavaScript to be explicitly enabled on macOS.



David


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

On 4/28/19 12:01 AM, Timo Paulssen wrote:

especially if it iterates your entire home directory


Don't think so


$ rm -rf ~/.perl6/precomp

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :  13.201
Stage syntaxcheck:   0.000
Stage ast:   0.000
Stage optimize   :   0.362
Stage mast   :   1.099
Stage mbc:   0.029
Stage moar   :   0.000
GetUpdates.pl6
Mozilla Mirror 
Debug is OFF

Does this have anyting to do with it?

17: use lib '/home/linuxutil/p6lib';

'use lib' may not be pre-compiled
at /home/linuxutil/p6lib/CurlUtils.pm6 (CurlUtils):17


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users





Hi Timo,

This tell you anything?

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :  13.150
Stage syntaxcheck:   0.000
Stage ast    :   0.000
Stage optimize   :   0.351
Stage mast   :   1.133
Stage mbc    :   0.019
Stage moar   :   0.000

GetUpdates.pl6  <-- my program starts here
Mozilla Mirror 
Debug is OFF


The "Stage parse : 13.150" is eating me alive!

-T


On 4/28/19 12:01 AM, Timo Paulssen wrote:> Please give this a try:
>
>  env RAKUDO_MODULE_DEBUG=1 perl6 GetUpdates.pl6
>
> and tell me if any of the lines it spits out takes considerable amounts
> of time before the next one shows up.
>
> Then, you can also
>
>  strace -e stat perl6 GetUpdates.pl6
>
> to see if it's going through a whole load of files.
>
> without the "-e stat" you will get a whole lot more output, but it'll
> tell you pretty much everything that it's asking the kernel to do.
> Pasting that whole file could be a privacy concern, especially if it
> iterates your entire home directory, which is still my working 
hypothesis.

>
> HTH
>- Timo
>

My home directory is pretty small, except for .wine.
All the good stuff is on my network shares to share
with my numerous VM's


$ env RAKUDO_MODULE_DEBUG=1 perl6 GetUpdates.pl6 >   GetUpdates.debug 2>&1
http://vpaste.net/xmwcd


$ strace -e stat perl6 GetUpdates.pl6 > GetUpdates.debug 2>&1
http://vpaste.net/8ekeI


Re: Why so slow

2019-04-28 Thread Timo Paulssen

Please give this a try:

    env RAKUDO_MODULE_DEBUG=1 perl6 GetUpdates.pl6

and tell me if any of the lines it spits out takes considerable amounts 
of time before the next one shows up.


Then, you can also

    strace -e stat perl6 GetUpdates.pl6

to see if it's going through a whole load of files.

without the "-e stat" you will get a whole lot more output, but it'll 
tell you pretty much everything that it's asking the kernel to do. 
Pasting that whole file could be a privacy concern, especially if it 
iterates your entire home directory, which is still my working hypothesis.


HTH
  - Timo

On 28/04/2019 08:41, ToddAndMargo via perl6-users wrote:

> On 21/04/2019 05:58, ToddAndMargo via perl6-users wrote:>> Hi All,
>>
>> One liners are fast, but my own programs are very slow to start.
>>
>> I download
>>
>> https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6
>>
>> To check it out and it also takes ten second to start.
>>
>> What gives?
>>
>> Many thanks,
>> -T

On 4/27/19 11:14 PM, Timo Paulssen wrote:
You don't happen to have a PERL6LIB or -I pointed at a folder with 
loads of stuff in it? If that is the case, having a single "use" 
statement will cause rakudo to iterate through all files and 
subfolders, which can take a long time if you've got, for example, 
your home directory in that list (be it via -I. or PERL6LIB=. or 
explicitly mentioning the big folder)


There's many different tools to find out what's going on. For the 
"too big perl6lib folder" problem, "strace" will give you a good hint 
by giving one "stat" command for every file under your home directory.


Other than that, check "perl6 --stagestats -e 'blah'" or "perl6 
--stagestats FooBar.p6", which will give timings for the different 
phases, most notably "parse", "optimize", and "mbc". loading modules 
and precompiling are part of the parse stage.


the "time" command will split your run time between "system" and 
"user" time (as well as wallclock time). if "system" is particularly 
high, then the program spends a lot of time asking the kernel to do 
stuff (such as iterating files on the filesystem for the PERL6LIB 
case i've menitoned above).


If none of that helps, startup can be profiled with "perl6 
--profile-compile blah" and run time can be profiled with "perl6 
--profile blah". The default output will be a html file that you can 
just open in your browser to get an interactive performance 
inspection tool thingie. Be aware, though, that it can become very 
big in the case of --profile-compile, depending on the structure of 
the program being compiled.


Hope any of that helps
   - Timo



Hi Timo,

This tell you anything?

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :  13.150
Stage syntaxcheck:   0.000
Stage ast    :   0.000
Stage optimize   :   0.351
Stage mast   :   1.133
Stage mbc    :   0.019
Stage moar   :   0.000

GetUpdates.pl6  <-- my program starts here
Mozilla Mirror 
Debug is OFF


The "Stage parse : 13.150" is eating me alive!

-T


Re: Why so slow

2019-04-28 Thread David Christensen

On 21/04/2019 05:58, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6


To check it out and it also takes ten second to start. >>
What gives?

Many thanks, -T



On 4/27/19 11:14 PM, Timo Paulssen wrote:

You don't happen to have a PERL6LIB or -I pointed at a folder with
loads of stuff in it? If that is the case, having a single "use"
statement will cause rakudo to iterate through all files and
subfolders, which can take a long time if you've got, for example,
your home directory in that list (be it via -I. or PERL6LIB=. or
explicitly mentioning the big folder)

There's many different tools to find out what's going on. For the
"too big perl6lib folder" problem, "strace" will give you a good hint
by giving one "stat" command for every file under your home
directory.

Other than that, check "perl6 --stagestats -e 'blah'" or "perl6 
--stagestats FooBar.p6", which will give timings for the different 
phases, most notably "parse", "optimize", and "mbc". loading modules

and precompiling are part of the parse stage.

the "time" command will split your run time between "system" and
"user" time (as well as wallclock time). if "system" is particularly
high, then the program spends a lot of time asking the kernel to do
stuff (such as iterating files on the filesystem for the PERL6LIB
case i've menitoned above).

If none of that helps, startup can be profiled with "perl6 
--profile-compile blah" and run time can be profiled with "perl6 
--profile blah". The default output will be a html file that you can

 just open in your browser to get an interactive performance
inspection tool thingie. Be aware, though, that it can become very
big in the case of --profile-compile, depending on the structure of
the program being compiled.

Hope any of that helps - Timo



Yes, very useful -- thank you.  :-)


(I do not seem to have a man page for Perl 6, but 'perl6 --help' gives a 
brief overview of those options.)



The only drawback is that the HTML profile reports require JavaScript
and a live Internet connection to function.


David


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

> On 21/04/2019 05:58, ToddAndMargo via perl6-users wrote:>> Hi All,
>>
>> One liners are fast, but my own programs are very slow to start.
>>
>> I download
>>
>> https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6
>>
>> To check it out and it also takes ten second to start.
>>
>> What gives?
>>
>> Many thanks,
>> -T

On 4/27/19 11:14 PM, Timo Paulssen wrote:
You don't happen to have a PERL6LIB or -I pointed at a folder with loads 
of stuff in it? If that is the case, having a single "use" statement 
will cause rakudo to iterate through all files and subfolders, which can 
take a long time if you've got, for example, your home directory in that 
list (be it via -I. or PERL6LIB=. or explicitly mentioning the big folder)


There's many different tools to find out what's going on. For the "too 
big perl6lib folder" problem, "strace" will give you a good hint by 
giving one "stat" command for every file under your home directory.


Other than that, check "perl6 --stagestats -e 'blah'" or "perl6 
--stagestats FooBar.p6", which will give timings for the different 
phases, most notably "parse", "optimize", and "mbc". loading modules and 
precompiling are part of the parse stage.


the "time" command will split your run time between "system" and "user" 
time (as well as wallclock time). if "system" is particularly high, then 
the program spends a lot of time asking the kernel to do stuff (such as 
iterating files on the filesystem for the PERL6LIB case i've menitoned 
above).


If none of that helps, startup can be profiled with "perl6 
--profile-compile blah" and run time can be profiled with "perl6 
--profile blah". The default output will be a html file that you can 
just open in your browser to get an interactive performance inspection 
tool thingie. Be aware, though, that it can become very big in the case 
of --profile-compile, depending on the structure of the program being 
compiled.


Hope any of that helps
   - Timo



Hi Timo,

This tell you anything?

$ perl6 --stagestats GetUpdates.pl6
Stage start  :   0.000
Stage parse  :  13.150
Stage syntaxcheck:   0.000
Stage ast:   0.000
Stage optimize   :   0.351
Stage mast   :   1.133
Stage mbc:   0.019
Stage moar   :   0.000

GetUpdates.pl6  <-- my program starts here
Mozilla Mirror 
Debug is OFF


The "Stage parse : 13.150" is eating me alive!

-T


Re: Why so slow

2019-04-28 Thread ToddAndMargo via perl6-users

On 4/27/19 10:40 PM, David Christensen wrote:
What is your operating system?  


Fedora 29 x64
Xfce 4.13
$ uname -r
5.0.7-200.fc29.x86_64



What is your Perl 6?


$ rpm -qa rakudo
rakudo-0.2019.03-1.fc29.x86_64

Also tried:
https://github.com/nxadm/rakudo-pkg/releases
 rakudo-pkg-Fedora29-2018.11-01.x86_64.rpm
 rakudo-pkg-Fedora29-2019.03.1-01.x86_64.rpm
No symptom change


Re: Why so slow

2019-04-28 Thread Timo Paulssen
You don't happen to have a PERL6LIB or -I pointed at a folder with loads 
of stuff in it? If that is the case, having a single "use" statement 
will cause rakudo to iterate through all files and subfolders, which can 
take a long time if you've got, for example, your home directory in that 
list (be it via -I. or PERL6LIB=. or explicitly mentioning the big folder)


There's many different tools to find out what's going on. For the "too 
big perl6lib folder" problem, "strace" will give you a good hint by 
giving one "stat" command for every file under your home directory.


Other than that, check "perl6 --stagestats -e 'blah'" or "perl6 
--stagestats FooBar.p6", which will give timings for the different 
phases, most notably "parse", "optimize", and "mbc". loading modules and 
precompiling are part of the parse stage.


the "time" command will split your run time between "system" and "user" 
time (as well as wallclock time). if "system" is particularly high, then 
the program spends a lot of time asking the kernel to do stuff (such as 
iterating files on the filesystem for the PERL6LIB case i've menitoned 
above).


If none of that helps, startup can be profiled with "perl6 
--profile-compile blah" and run time can be profiled with "perl6 
--profile blah". The default output will be a html file that you can 
just open in your browser to get an interactive performance inspection 
tool thingie. Be aware, though, that it can become very big in the case 
of --profile-compile, depending on the structure of the program being 
compiled.


Hope any of that helps
  - Timo

On 21/04/2019 05:58, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


Re: Why so slow

2019-04-27 Thread David Christensen

On 4/20/19 8:58 PM, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T



We discussed this at our San Francisco Perl Mongers meeting today:

1.  Works for me:

2019-04-27 22:32:13 dpchrist@tinkywinky ~
$ cat /etc/debian_version
9.8

2019-04-27 22:32:18 dpchrist@tinkywinky ~
$ uname -a
Linux tinkywinky 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) 
x86_64 GNU/Linux


2019-04-27 22:32:21 dpchrist@tinkywinky ~
$ ls Downloads/rakudo-pkg-Debian9_2019.03.1-01_amd64.deb
Downloads/rakudo-pkg-Debian9_2019.03.1-01_amd64.deb

2019-04-27 22:32:23 dpchrist@tinkywinky ~
$ dpkg-query --list rakudo*
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  rakudo-pkg 2019.03.1-01 amd64Rakudo Perl 6 runtime

2019-04-27 22:32:30 dpchrist@tinkywinky ~
$ cat sandbox/perl6/hello.p6
#!/usr/bin/env perl6
print "hello, world!\n";

2019-04-27 22:32:37 dpchrist@tinkywinky ~
$ time sandbox/perl6/hello.p6
hello, world!

real0m0.276s
user0m0.332s
sys 0m0.068s

2.  Worked for another person with macOS.

3.  10~15 second start-up delays for another person with Debian 9 and 
Perl 6 built from source.  top(1) showed 100+ %CPU during the start-up 
delays.  Once inside the REPL, there were no obvious delays.  I 
suggested that he install the official package:


https://rakudo.org/files


What is your operating system?  What is your Perl 6?


Is there a way to run Perl 6 with debugging, logging, profiling, etc., 
enabled, so that the user can see what Perl 6 is doing and how long it 
takes?



David


Re: Why so slow

2019-04-27 Thread Brad Gilbert
>From 
>https://brrt-to-the-future.blogspot.com/2018/07/perl-6-on-moarvm-has-had-jit-for-few.html

> PS: You might read this and be reasonably surprised that Rakudo Perl 6 is 
> not, after all this, very fast yet. I have a - not entirely serious - 
> explanation for that:

> 1. All problems in computer science can be solved with a layer of indirection.
> 2. Many layers of indirection make programs slow.
> 3. Perl 6 solves many computer science problems for you ;-)

>. In the future, we'll continue to solve those problems, just faster.

Basically, even minor things like adding two numbers together, involve
half a dozen or more layers of indirection.
(The optimizer eliminates some of the needless layers of indirection.)

On Sat, Apr 27, 2019 at 6:53 PM ToddAndMargo via perl6-users
 wrote:
>
> On 4/20/19 8:58 PM, ToddAndMargo via perl6-users wrote:
> > Hi All,
> >
> > One liners are fast, but my own programs are very slow to start.
> >
> > I download
> >
> > https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6
> >
> > To check it out and it also takes ten second to start.
> >
> > What gives?
> >
> > Many thanks,
> > -T
>
>
> For comparison purposes, I do have similar sized Perl 5 programs
> with similar amounts of modules, that start almost instantly.


Re: Why so slow

2019-04-27 Thread ToddAndMargo via perl6-users

On 4/20/19 8:58 PM, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T



For comparison purposes, I do have similar sized Perl 5 programs
with similar amounts of modules, that start almost instantly.


Re: Why so slow

2019-04-24 Thread ToddAndMargo via perl6-users





Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T



On 4/24/19 5:13 AM, Brad Gilbert wrote:> For one it has the following line:
>
>  use lib 'lib';
>
> That is going to slow everything down if you have anything in the
> `lib` directory.
> The more things in that directory, the slower it will get.
>
> You should really install the modules with `zef`. (It can download and
> install the modules itself.)
>
> Also it isn't until the very last line of that program that anything
> visible happens.
>
> Basically it has a lot of work to do before it can make itself visible.
>
> On Wed, Apr 24, 2019 at 2:46 AM ToddAndMargo via perl6-users
>  wrote:

Hi Brad,

I just used that as an example that could be downloaded, rather than
posting my own code.  Commenting out the "use lib" made no
difference.  It takes ten second for my code to start.

Also, I do not understand what you mean by "zef".  If I don't
use zef to install the modules called out, my code won't run.

-T


Re: Why so slow

2019-04-24 Thread Brad Gilbert
For one it has the following line:

use lib 'lib';

That is going to slow everything down if you have anything in the
`lib` directory.
The more things in that directory, the slower it will get.

You should really install the modules with `zef`. (It can download and
install the modules itself.)

Also it isn't until the very last line of that program that anything
visible happens.

Basically it has a lot of work to do before it can make itself visible.

On Wed, Apr 24, 2019 at 2:46 AM ToddAndMargo via perl6-users
 wrote:
>
> Hi All,
>
> One liners are fast, but my own programs are very slow to start.
>
> I download
>
> https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6
>
> To check it out and it also takes ten second to start.
>
> What gives?
>
> Many thanks,
> -T


Why so slow

2019-04-24 Thread ToddAndMargo via perl6-users

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


Re: Why so slow?

2019-04-23 Thread ToddAndMargo via perl6-users

On 4/21/19 6:32 PM, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


I just upgraded from

rakudo-pkg-Fedora29-2018.11-01.x86_64.rpm

to

rakudo-pkg-Fedora29-2019.03.1-01.x86_64.rpm

Still ssl


Re: Why so slow?

2019-04-23 Thread ToddAndMargo via perl6-users

On 4/22/19 4:21 AM, ToddAndMargo via perl6-users wrote:



On 22/04/2019 12:51, ToddAndMargo via perl6-users wrote:

On 22/04/2019 03:32, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


On 4/22/19 3:35 AM, Timo Paulssen wrote:

It's quite possible that when you start that program, you're first
waiting for GTK::Simple to be precompiled; the "use lib 'lib'" can
interfere with the storage of precompilation results. If you have
installed GTK::Simple (for example by going to its folder and running
"zef install .") and removed the line "use lib 'lib';", it might 
start a

lot faster when you run it the second time.

Hope that helps!
    - Timo





Not seeing a `use lib`.  :'(

use v6;
use lib 'lib';
use GTK::Simple;
use GTK::Simple::App;


On 4/22/19 4:02 AM, Timo Paulssen wrote:> It's the second line:
 >
 > use v6;
 > use lib 'lib';  # ← this line right here
 > use GTK::Simple;
 > use GTK::Simple::App;
 >
 >    -Timo
 >

Made no difference.  :'(



Anyone?



--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~


Re: Why so slow?

2019-04-22 Thread ToddAndMargo via perl6-users




On 22/04/2019 12:51, ToddAndMargo via perl6-users wrote:

On 22/04/2019 03:32, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


On 4/22/19 3:35 AM, Timo Paulssen wrote:

It's quite possible that when you start that program, you're first
waiting for GTK::Simple to be precompiled; the "use lib 'lib'" can
interfere with the storage of precompilation results. If you have
installed GTK::Simple (for example by going to its folder and running
"zef install .") and removed the line "use lib 'lib';", it might start a
lot faster when you run it the second time.

Hope that helps!
    - Timo





Not seeing a `use lib`.  :'(

use v6;
use lib 'lib';
use GTK::Simple;
use GTK::Simple::App;


On 4/22/19 4:02 AM, Timo Paulssen wrote:> It's the second line:
>
> use v6;
> use lib 'lib';  # ← this line right here
> use GTK::Simple;
> use GTK::Simple::App;
>
>-Timo
>

Made no difference.  :'(


Re: Why so slow?

2019-04-22 Thread Timo Paulssen
It's the second line:

use v6;
use lib 'lib';  # ← this line right here
use GTK::Simple;
use GTK::Simple::App;

  -Timo

On 22/04/2019 12:51, ToddAndMargo via perl6-users wrote:
>>> On 22/04/2019 03:32, ToddAndMargo via perl6-users wrote:
>>>> Hi All,
>>>>
>>>> One liners are fast, but my own programs are very slow to start.
>>>>
>>>> I download
>>>>
>>>> https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6
>>>>
>>>> To check it out and it also takes ten second to start.
>>>>
>>>> What gives?
>>>>
>>>> Many thanks,
>>>> -T
>
> On 4/22/19 3:35 AM, Timo Paulssen wrote:
>> It's quite possible that when you start that program, you're first
>> waiting for GTK::Simple to be precompiled; the "use lib 'lib'" can
>> interfere with the storage of precompilation results. If you have
>> installed GTK::Simple (for example by going to its folder and running
>> "zef install .") and removed the line "use lib 'lib';", it might start a
>> lot faster when you run it the second time.
>>
>> Hope that helps!
>>    - Timo
>>
>
>
>
> Not seeing a `use lib`.  :'(
>
> use v6;
> use lib 'lib';
> use GTK::Simple;
> use GTK::Simple::App;


Re: Why so slow?

2019-04-22 Thread ToddAndMargo via perl6-users

On 22/04/2019 03:32, ToddAndMargo via perl6-users wrote:

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


On 4/22/19 3:35 AM, Timo Paulssen wrote:

It's quite possible that when you start that program, you're first
waiting for GTK::Simple to be precompiled; the "use lib 'lib'" can
interfere with the storage of precompilation results. If you have
installed GTK::Simple (for example by going to its folder and running
"zef install .") and removed the line "use lib 'lib';", it might start a
lot faster when you run it the second time.

Hope that helps!
   - Timo





Not seeing a `use lib`.  :'(

use v6;
use lib 'lib';
use GTK::Simple;
use GTK::Simple::App;


Re: Why so slow?

2019-04-22 Thread Timo Paulssen
It's quite possible that when you start that program, you're first
waiting for GTK::Simple to be precompiled; the "use lib 'lib'" can
interfere with the storage of precompilation results. If you have
installed GTK::Simple (for example by going to its folder and running
"zef install .") and removed the line "use lib 'lib';", it might start a
lot faster when you run it the second time.

Hope that helps!
  - Timo

On 22/04/2019 03:32, ToddAndMargo via perl6-users wrote:
> Hi All,
>
> One liners are fast, but my own programs are very slow to start.
>
> I download
>
> https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6
>
> To check it out and it also takes ten second to start.
>
> What gives?
>
> Many thanks,
> -T


Why so slow?

2019-04-21 Thread ToddAndMargo via perl6-users

Hi All,

One liners are fast, but my own programs are very slow to start.

I download

https://github.com/perl6/gtk-simple/blob/master/examples/05-bars.pl6

To check it out and it also takes ten second to start.

What gives?

Many thanks,
-T


DateTime.Str default formatter with sprintf is pretty slow

2017-09-19 Thread Thor Michael Støre
Hey,

When I profiled my "read CSV, munge, write CSV" script to see why it is a bit 
on the slow side DateTime.Str stood out. I saw the default formatter eventually 
reached sprintf, which consumed a lot of time. Each output line from my script 
has one date and time in ISO 8601 format, and when I changed the script so that 
they were stringified without sprintf the total runtime dropped from ~7 to ~4.5 
seconds on a short run that converts 800 lines to 1100.

A test case for this:

#!/usr/bin/env perl6

# Arg: Quick DateTime
sub MAIN( :$qDT = False ) {
while my $x++ < 1000 {
say DateTime.new( year => 2017, hour => (^24).roll, minute => 
(^60).roll,
  formatter => ( $qDT ??  !! Callable ) );
}
}

sub formatISO8601( DateTime $dt ) {
( 0 > $dt.year ?? '-'~ zPad( $dt.year.abs, 4 ) !!
  $dt.year <=  ?? zPad( $dt.year, 4 )
   !! '+'~ zPad( $dt.year, 5 ) ) ~'-'~
zPad( $dt.month, 2 ) ~'-'~ zPad( $dt.day, 2 ) ~'T'~
zPad( $dt.hour, 2 ) ~':'~ zPad( $dt.minute, 2 ) ~':'~
   ( $dt.second.floor == $dt.second
   ?? zPad( $dt.second.Int, 2 )
   !! $dt.second.fmt('%09.6f') )
 ~
 ( $dt.timezone == 0
   ?? 'Z'
   !! $dt.timezone > 0
  ?? ( '+' ~ zPad( ($dt.timezone/3600).floor, 2 ) ~':'~
 zPad( ($dt.timezone/60%60).floor, 2 ) )
  !! ( '-' ~ zPad( ($dt.timezone.abs/3600).floor, 2 ) ~':'~
 zPad( ($dt.timezone.abs/60%60).floor, 2 ) ) )
}

sub zPad($s, $p) {'0' x $p - $s.chars ~ $s}

Running that with —qDT results in a bit less than a 4x speedup for me, with 
results piped to /dev/null. I wouldn’t know whether doing something like this 
in general is a good idea, of if sprintf/fmt should be improved.

Putting together that example, I noticed that Date.today also seems slow, 
taking about twice as long as DateTime.new. Replacing "year => 2017” with "date 
=> Date.today" in the example above slows it down by about 400ms on my (slow) 
laptop computer. I don't call that in a loop like in this in my actual script 
anyhow, so that's no biggie for me, but it’s the sort of thing that might get 
put in a tight loop so it’s something to be aware of.

---
Thor Michael Støre
thormich...@gmail.com
Database guy in Kongsberg, Norway
Mobile: +47 97 15 14 09



Re: perl6 --profile-compile | --profile: both very slow and depend on Internet resources

2016-04-01 Thread Tom Browder
On Fri, Apr 1, 2016 at 10:08 AM, Tom Browder  wrote:
> On Fri, Apr 1, 2016 at 9:39 AM, Timo Paulssen  wrote:
>> The profiler's data blob is a massive, gigantic blob of json (ls the file
>> and you'll see).
>
> Ah, yes:  a 2.8+ million character line!
...
> What about creating a text output in a format something like gprof?
> It looks like tadzik has some code that could be used as a start.

And look at something like:

  https://github.com/open-source-parsers/jsoncpp

to use as the JSON C++ library.

-Tom


Re: perl6 --profile-compile | --profile: both very slow and depend on Internet resources

2016-04-01 Thread Timo Paulssen



On 01/04/16 17:08, Tom Browder wrote:



Alternatively, there's a qt-based profiler up on tadzik's github that can
read the json blob (you will have to --profile-filename=blahblah.json to get
that), but it doesn't evaluate as much of the data - it'll potentially even
fail completely what with the recent changes i made :S

...

That looks like the place to start to me...


The one big problem with the qt-based profiler is that the json library 
it uses refuses to work with files over a certain limit, and we easily 
reach that limit. So that's super dumb :(

  - Timo


Re: perl6 --profile-compile | --profile: both very slow and depend on Internet resources

2016-04-01 Thread Timo Paulssen
The profiler's data blob is a massive, gigantic blob of json (ls the 
file and you'll see).


You can easily search the urls to point at local files instead 
of the CDN.


Alternatively, there's a qt-based profiler up on tadzik's github that 
can read the json blob (you will have to 
--profile-filename=blahblah.json to get that), but it doesn't evaluate 
as much of the data - it'll potentially even fail completely what with 
the recent changes i made :S


The biggest contributor to filesize for the profiler is the complexity 
of the call tree. If you can cut out parts and pieces of your program, 
you should be able to profile them individually just fine.


In my experience, firefox is more likely to work with the big profiles.

If anybody is interested in improving our html/js profiler front-end, 
please do speak up and you'll be showered with as much guidance and 
praise as you need :)

  - Timo


perl6 --profile-compile | --profile: both very slow and depend on Internet resources

2016-04-01 Thread Tom Browder
Is there any easy way to get the profilers to use local code (css, js,
etc.) rather than reading across a sometimes slow internet connection?

I'm using both Chrome and Iceweasel with the same effects: slow
loading scripts and always seem to be reading:

https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css;>
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap-theme.min.css;>

Thanks.

Best regards,

-Tom