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

[Ivica Bukvic]

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. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200613/85340d2a/attachment-0001.html>