|
Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec Set by moderator on 17 March 2017. |
|||
|
02:49
ilbot3 joined
|
|||
| moderator | Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec | ||
|
02:59
ribasushi joined
08:50
domidumont joined
12:32
tadzik joined
|
|||
| ugexe | nine: do you have any idea how much time is spent parsing json when loading/installing? | 16:23 | |
| I'm wondering if a meta6.json specific parser could be useful for speed purposes | 16:24 | ||
| as in - it already has an expected format so it could possibly make assumptions to speed up what its searching for | |||
| I ask because zef has to do things like load the entire ecosystem json at once, and this process is slow for things like smoke testing (it loads the json for each module it attempts to smoke) so I may end up writing something one way or another | 16:26 | ||
| nine | ugexe: module loading does not parse any json at all | 16:37 | |
| For installation I figure the parse time is drowned by precompilation and most of all tests | |||
| ugexe | do you know if it *did* have to parse json per-load (so not loading it for modules that don't get loaded like pre 2016) if it would be significant? | 16:40 | |
| also if you get a chance, could you respond to the last 3 comments here: github.com/ugexe/zef/issues/117 ? Its a debian packager questioning why a precomp is being created in ~/.perl6 when using a module that has a precomp installed to site already | 16:42 | ||
| If I remember correctly thats something that would eventually be fixed, but for now we have to just deal with it? | 16:43 | ||
| nine | ugexe: oh that has been fixed for more than half a year | 18:16 | |
| Without reading through the whole thread I'd guess that the installed precomp file is considered out of date due to some dependency being updated (via zef for example) | 18:17 | ||
| ugexe | his examples all seem to be with just `perl6 -MTest -e 'say "hello\\n";'` though | 18:18 | |
| nine | Regarding the updating of precomp files when rakudo is updated - that is Debian's job! They have to trigger a rebuild of the module-packages when they update their rakudo package. But that's on their build farm not on the user's computer. | ||
| Running with RAKUDO_MODULE_DEBUG=1 usually answer's questions like "Why is the file re-generated?" quite well. Most of all because I asked that question 100s of times during development :) | 18:19 | ||
| ugexe | `rm -rf ~/.perl6/precomp/ && perl6 -MTest -e 'say "hello\\n";'` he basically does this, which creates a precomp in ~/.perl6 (but Test was precompiled when it was installed with rakudo) | ||
| nine | Trying exactly that on my system I get: | 18:20 | |
| 2 12939 RMD: Loading precompiled | |||
| /home/nine/rakudo/install/share/perl6/precomp/8501BB087A2B6D8B470D29FD5A39FFE199D0B672.1489220495.56848/C7/C712FE6969F786C9380D643DF17E85D06868219E | |||
| So I guess debian's rakudo package is just broken. | 18:21 | ||
| ugexe | hmmm, in his strace it shows that it first stats the precompiled file in site/perl6, but continues to then stat the precomp in ~/.perl6 | 18:23 | |
| [pid 9338] open("/usr/share/perl6/sources/A9948E7371E0EB9AFDF1EEEB07B52A1B75537C31", O_RDONLY|O_CLOEXEC) = 11 | |||
| nine | RAKUDO_MODULE_DEBUG=1 is much better than strace for debugging this | ||
| ugexe | [pid 9338] open("/home/domi/.perl6/precomp/ED429562BF693CB189D0808E8C54097E4896CD6C.1489325966.69235/A9/A9948E7371E0EB9AFDF1EEEB07B52A1B75537C31.bc", O_RDWR|O_CREAT|O_TRUNC, 0666) = 35 | ||
| nine | Because it tells you _why_ it rejects the precomp file | 18:24 | |
| ugexe | RAKUDO_MODULE_DEBUG=1 shows me it loads the Test from share/perl6/precomp, but it still *creates* files in ~/.perl6 | 18:29 | |
| reproduced with RAKUDO_MODULE_DEBUG=1 here: gist.github.com/ugexe/9ceecb06673d...d27571615c | 18:33 | ||
| nine | it creates a .repo-id file? | 18:46 | |
| ugexe | Good catch - my only creates a repo-id file while his creates a repo-id file as well as an additional file | 18:54 | |
| If I `chattr +i ~/.perl6` and then `perl6 -e 'use Test;'` I get a ===SORRY!=== Failed to create directory | 19:01 | ||
| Does the repo-id file not get created for you in ~/.perl6 ? | 19:42 | ||
| nine | Oh it does as it should. It is the identity of all repositories at the time when a precomp file's dependencies were re-checked. | 22:17 | |
| On installation we precompile the dependencies. On the first run afterwards, we usually have different repositories - at least ~/.perl6 is added to the list. As it could contain updated dependencies, we have to re-run the dependency resolution. | 22:18 | ||
| On all following runs, we can just compare the identity of the current repository chain with the id in the .repo-id file. If they're equal, we don't have to run the costly re-resolving and instead can just load the full list. | 22:19 | ||