Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
04:47 sena_kun left 04:57 sena_kun joined 10:35 jnthn is now known as jnthnwrthngtn 11:12 Geth left, Geth joined 15:04 Geth left, Geth joined
lizmat gist.github.com/lizmat/ea4cd9c154f...9674f0b841 # pre-compiling Cro::HTTP::Client 17:00
I basically need to do the equivalent of: (run 'curl', $url, :out, :!err).out.slurp 17:01
I'm seriously considering not using Cro for this type of function anymore 17:02
am I wrong ?
jnthnwrthngtn What's the problem? 17:04
I'm pretty sure curl is a bigger codebase than Cro :P 17:05
And also, if you're doing many queries to the same server, you can't take advantage of keepalive and so forth
Also if you need headers etc you'd need to parse stuff. If you want many folks to run it then curl it's universally installed. And so forth. 17:08
I suspect most Cro users aren't reinstalling their Rakudo so regularly as you are, so don't really feel the recompilation pain. :) 17:09
oops, curl *isn't* universally installed
Pretty sure it's one of the first things I end up installing on new Ubuntu installations :) 17:10
lizmat yeah, it's that really... I have no other performance issues... but each rakudo compile takes now well over a minute to re-precompile Cro::HTTP::Client
jnthnwrthngtn *nod*
lizmat which really breaks the flow for me :-(
I guess that just boils down to: we need to make parsing faster 17:11
jnthnwrthngtn Right. I'm not sure there's not to be done on the Cro side about that, really; the dependency chain looks reasonable to me for a fairly full-featured HTTP client 17:12
lizmat It's just that I don't need a lot of the features ?
also, if we could have in process pre-compilation again, that would save already 82 * .15 = 12.3 seconds 17:14
jnthnwrthngtn Maybe not, although a chunk of it is for example because of HTTPS, which these days most folks need
The Log::Timeline bit is maybe the most "why am I paying for this"
It should perhaps lazy-load CBOR for example 17:15
japhb
.oO( Why do my modules always end up getting noticed in the wrong ways? )
lizmat also: it feels that any modules at the same top-level should in principle be pre-compilable in parallel ? 17:16
e.g. from Cro::HTTP::Body: 17:17
Precompiling Cro::HTTP::Body
Precompiling Cro::HTTP::Header
Precompiling Cro::MediaType
Precompiling Cro::HTTP::MultiValue
feels like Cro::HTTP::Header / MediaType / HTTP::MultiValue could be done in parallel ?
I guess we need more meta info in the precomp "database" 17:18
jnthnwrthngtn Probably they can be but one maybe has to know the whole tree to know what to do, etc. 17:22
Or at least it's easier to avoid wasted work in-process
lizmat right, and we can't atm
jnthnwrthngtn Home time for me 17:23
lizmat safe travels!
jnthnwrthngtn Yeah, hopefully the snow hasn't turned to ice :)
o/
Skarsnik_ lizmat, http::useragent is not enought? 20:29
lizmat possibly, but then I'd just settle for even less Raku dependencies by calling curl :-) 21:03
Skarsnik_ and yes, precompile time being slow is super annoying, especially if you change a rakumod used by other rakumod. 21:05
lizmat even worse if you recompile the setting... then *everything* needs to be re-pre-compiled 21:06
which is still better than before, because there has been a time when a re-compilation of the setting meant you had to *re-install* all modukes 21:07
*modules
Skarsnik_ I also remember pre 6.c with no precomp x) 20 sec when changing a module file? 21:12
or even when chaning nothing but using lot of modules ^^
22:32 Geth left, Geth joined 22:36 Geth left, Geth joined 22:41 Geth left, Geth joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!