Right, probably 80-85% of the startup time is in the C++ method
factor_vm::load_image.
Breaking it down further:
- 32% of the startup time is factor_vm::load_data_heap
- 15% of the startup time is factor_vm::load_code_heap
- 32% of the startup time is factor_vm::fixup_heaps
It's on the list to dig into but if you'd like, you could look there and
see if there are improvements to be made.
Best,
John.
On Sun, Feb 5, 2017 at 7:19 AM, <pet...@riseup.net> wrote:
> 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
>
------------------------------------------------------------------------------
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
