[L2Ork-dev] Node.js multithreading: What are Worker threads, and why do they matter? - LogRocket Blog

Sat Jun 13 15:58:16 EDT 2020

So, why don't we approach the console print out the same way as scheduling
of scrollbar updates whereby the console function collects all the messages
in the order they have been received and schedules a single print out so
many times per second? That said, this in and out itself will still not
solve the Twitter slowdown because in my case even a single post message
after the console log gets excessively large will cause a slowdown which
suggests that the process of printing it at the bottom of the console and
possibly grouping it with previous identical messages may be too CPU
intensive.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sat, Jun 13, 2020, 14:00 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:

> On Sat, Jun 13, 2020 at 9:06 AM Ivica Bukvic <ico at vt.edu> wrote:
> >
> > I don't think it is the number of messages sent at once (although if one
> sends thousands of lines in a single update it may have an adverse
> effect--i just haven't seen it being an issue even with larger dumps when
> the console log is short). During debugging, Tweeter can send several
> hundred in a single update.
>
> Check out DevTools-- you can record performance for a few seconds and
> it will give you a graph showing
> how often the GUI is doing a relayout.
>
> If you're calling print or post several hundred times then you're
> probably triggering a relayout each time. Collecting
> those into a documentFragment and doing a single DOM mutation will
> give a 100x or more efficient if that's the
> case.
>
> -Jonathan
>
> > This is, however, not a problem until you have long enough of the log. I
> suspect it is the process of searching through the log where to append the
> message and grouping the same ones that may be the culprit. Once you have
> several hundred messages in the queue, the slowdown becomes increasingly
> apparent even when you send a single line (this is the scenario I shared
> with you via the conference call). How cpu intensive is to group the same
> messages?
> >
> > Best,
> >
> > Ico
> >
> > --
> > Ivica Ico Bukvic, D.M.A.
> > Director, Creativity + Innovation
> > Institute for Creativity, Arts, and Technology
> >
> > Virginia Tech
> > Creative Technologies in Music
> > School of Performing Arts – 0141
> > Blacksburg, VA 24061
> > (540) 231-6139
> > ico at vt.edu
> >
> > www.icat.vt.edu
> > www.performingarts.vt.edu
> > l2ork.icat.vt.edu
> > ico.bukvic.net
> >
> > On Sat, Jun 13, 2020, 01:16 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>
> >> On Fri, Jun 12, 2020 at 10:29 PM Ivica Bukvic <ico at vt.edu> wrote:
> >> >
> >> > Another way I'm reading this is that this may be more reminiscent of
> what I've done in the 1.x branch where the console is running essentially
> in a separate TK thread to ensure that it does not have any bearing on the
> visual updates of the main thread. It reads from a queue which is being
> populated by the main thread, so that the console has no direct impact on
> the main thread. That said, this backgrounded process seems to be a bit
> different than what the TK has and may need to be investigated further.
> >>
> >> Just curious-- in your l2ork tweeter demo of this problem, how often
> >> were you sending messages to the Pd Window?
> >>
> >> -Jonathan
> >>
> >> >
> >> > Best,
> >> >
> >> > Ico
> >> >
> >> > --
> >> > Ivica Ico Bukvic, D.M.A.
> >> > Director, Creativity + Innovation
> >> > Institute for Creativity, Arts, and Technology
> >> >
> >> > Virginia Tech
> >> > Creative Technologies in Music
> >> > School of Performing Arts – 0141
> >> > Blacksburg, VA 24061
> >> > (540) 231-6139
> >> > ico at vt.edu
> >> >
> >> > www.icat.vt.edu
> >> > www.performingarts.vt.edu
> >> > l2ork.icat.vt.edu
> >> > ico.bukvic.net
> >> >
> >> > On Fri, Jun 12, 2020, 22:25 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >> >>
> >> >> On Fri, Jun 12, 2020 at 7:47 PM Ivica Bukvic <ico at vt.edu> wrote:
> >> >> >
> >> >> > This may be a way how to avoid console output bogging down the
> main GUI. Namely, running it in a background.
> >> >> >
> >> >> >
> https://blog.logrocket.com/node-js-multithreading-what-are-worker-threads-and-why-do-they-matter-48ab102f8b10/
> >> >>
> >> >> It looks like we've run into this before given the presence of
> >> >> throttle_console_scroll in pdgui.js. But that was just due
> >> >> to the slowness of the scrollbar itself.
> >> >>
> >> >> Probably an easier solution than a worker thread is to batch
> appending
> >> >> new stuff to the console when necessary:
> >> >>
> >> >> 1. when a message to the console arrives, print it immediately and
> set
> >> >> a timeout, say 30ms
> >> >> 2. during the timeout period, add incoming console messages to a
> >> >> documentFragment
> >> >> 3. at the end of the timeout, if there's content inside the
> >> >> documentFragment then append it to the console and start a new
> >> >> timeout. If there's no content then do nothing.
> >> >>
> >> >> That way if a user is thrashing the console, they only eat the cost
> of
> >> >> rendering at most every 30ms.
> >> >>
> >> >> -Jonathan
> >> >>
> >> >> >
> >> >> > Best,
> >> >> >
> >> >> > Ico
> >> >> >
> >> >> > --
> >> >> > Ivica Ico Bukvic, D.M.A.
> >> >> > Director, Creativity + Innovation
> >> >> > Institute for Creativity, Arts, and Technology
> >> >> >
> >> >> > Virginia Tech
> >> >> > Creative Technologies in Music
> >> >> > School of Performing Arts – 0141
> >> >> > Blacksburg, VA 24061
> >> >> > (540) 231-6139
> >> >> > ico at vt.edu
> >> >> >
> >> >> > www.icat.vt.edu
> >> >> > www.performingarts.vt.edu
> >> >> > l2ork.icat.vt.edu
> >> >> > ico.bukvic.net
> >> >> > _______________________________________________
> >> >> > L2Ork-dev mailing list
> >> >> > L2Ork-dev at disis.music.vt.edu
> >> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> >> _______________________________________________
> >> >> L2Ork-dev mailing list
> >> >> L2Ork-dev at disis.music.vt.edu
> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >> >
> >> > _______________________________________________
> >> > L2Ork-dev mailing list
> >> > L2Ork-dev at disis.music.vt.edu
> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> _______________________________________________
> >> L2Ork-dev mailing list
> >> L2Ork-dev at disis.music.vt.edu
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200613/e6a12446/attachment.html>