On Wed, 31 Aug 2022, 00:59 ToddAndMargo via perl6-users, < perl6-us...@perl.org> wrote:
> On 8/30/22 13:34, Richard Hainsworth wrote: > > Hi Todd, > > > <Snip> > > Since you continue for ever to complain about 'compile' time issues, > > "Stage parce" is specifically what I am whining about > > > rather than startup times, I wonder whether the programs you write are > > massive monolithic lines of code with thousands of lines, much like most > > standard software when FORTRAN or COBOL were the high level languages, > > or whether you design things to make each section more manageable. > > > $ raku -c --stagestats GetUpdates.pl6 > Stage start : 0.000 > Stage parse : 17.851 > Stage syntaxcheck: Syntax OK > > Perl 5 does it over 300 times faster on the code I ported > Raku and Perl are two different languages in the same family. They evolved with different targets, perl to react quickly to internet requests, Raku to be a better programming language. This may not be the take the actual developers have, but it's what I think happened. So the thing you designed for Perl will be faster because it fits the pattern. But it's not the best way for Raku. Even though stage parse will get significantly faster over time because Raku was designed to be optimisable, I think Perl will always be faster. Having said that Raku is still better because it separates out things that should be separate. So you may need to change the way you handle your task. Work with Raku rather than expect it to be the same as Perl. > > > > > If the programs you write to be run from the command line are thousands > > of lines long, then yes!! you will suffer!!! from long!!!! startup times Think about the difference between start up and parsing. Move as much stuff away from parsing as possible. > > because the program is re-compiled EVERY time. However, if you redesign > <Snip> > > Hi Richard, > > Long time no talk to you either. Don't be a stranger. > (If you like, I can always "whine" about compile times > to get your attention, if you like. Chuckle.) > > Thank you. That letter took a lot of work! > > How does this sound? > No. I think you are missing the explicit difference being made in Raku, which differs from all other languages I know (explicit since one could argue C preprocessing does the Sam) between compile time and run time. Raku explicitly allows you to specify compile time actions in the program itself. By saying above / below, this indicates a linear view of code at the same time. This distinction will become even greater when the new Macros are incorporated. That's the next version of Raku. > > BEGIN is a special block of code called a "phaser" > that runs at compile time. It will see any code > above it, such as variables and imported modules, > but not below it. > > Snip > > Can you show me an example of FIRST and LAST > > There are some in the documentation > > > Where .precomp does not work for me is my software > updates program. This is a behemoth program (imports > six of my custom modules too) that goes out and checks > for software updates that I support at my customer > sites. it is about 70 programs. > Change the way you do this to be more compliant with the realities of Raku. You may find in the refactoring process that your old way is probably subject to bit rot. > > To do this open the web site with firefox. Then I > use their developer's tools to examine the page's > source code. I find the fragment I am looking > for and regex them to extract them. > > In the process, I goof the regex/s "A LOT". Not > to mention having to chase down hidden character > that do not appear in Firefox's page source. > And download that are different on a web browser > than with curl. > > I do have a function that allows me to only run that > one web site's extraction, so I do not have to go > through all 70 of them. > > So, I have to recompile the code maybe up to 20 times > depending on the difficulty of the web site. The > L-O-N-G delays drives me nuts. > Treat the regexes as data for a program. Compile the program once. Run the regexes as often as you need. > > Snip. > > Speaking of BEGIN, is this Raku's "parallel > processing" method? Does Raku have a way to > spawn parallel processes and have them talk to > each other? > > -T > > Concurrency is a major change that Raku does differently. But it bursts my > head. Because concurrency is hard!!!!! > > > > > > > >
