On 2017-02-02 09:59, pet...@riseup.net wrote: > On 2017-02-01 22:39, John Benediktsson wrote: >> Feel free to jump in a profile startup and make some patches to >> improve >> things. >> >> Most languages seem to be under 50 milliseconds for the "startup and >> run no >> code" test case, so I would guess that should be fairly achievable. >> >> Best, >> John. >> >> On Wed, Feb 1, 2017 at 2:10 PM, <pet...@riseup.net> wrote: >> >>> On 2017-02-01 19:40, Jim Mack wrote: >>> > So why not create a separate small process that passes on its >>> > parameters to >>> > a running factor if it can find it, or starts a new one if it can't? >>> > >>> >>> That's like running a server and sending requests to it. I take >>> several >>> issues with that: >>> >>> 1 - I need one instance to have *all* my libraries, present and >>> future >>> to be pre-loaded. But more importantly: >>> 2 - a typical shell script can call a dozen external executables. >>> Some >>> will be in C, some in bash, some in python, some in perl etc. If >>> every >>> language would need a huge server to run, where would that leave us? >>> >>> > On Wed, Feb 1, 2017 at 7:51 AM, Timothy Hobbs <timo...@hobbs.cz> wrote: >>> > >>> >> Have you tried loading the >>> >> factor interpreter in the background and seeing if factor launches >>> >> quicker while another factor process is running? >>> >>> I did what I think is fair - started it once so everything necessary >>> gets cached in RAM and discard that run. As noted above I don't think >>> running a server for each possible language is a good solution. >>> >>> >>> Feel free to contradict me gentlemen, I'm open to discussion, but I >>> do >>> have my own opinion of what is acceptable and transferable to other >>> PCs >>> / colleagues. I'm not looking for some local hack to speed things up >>> but >>> a general solution that doesn't put any more burden on the end users >>> than it is necessary. >>> >>> -- >>> ------------ >>> Peter Nagy >>> ------------ >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Factor-talk mailing list >>> Factor-talk@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/factor-talk >>> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > I'd gladly take a look. Could you give me a hint how could I get > profiling statistics of the boot? I guess most of the startup time is > spent in factor code so I'd need to jack in a call to profile > somewhere and rebuild?
I did a quick check with sysdig on the time of system calls - it shows the base image takes ~50ms to load from my 180ms startup time (which isn't too bad for 115MB file I guess). No other interesting syscalls, so I guess the leftover 130ms are spent in factor. I'll try to take a look how could I get profiling statistics on the startup of the listener. -- ------------ Peter Nagy ------------ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
