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

Sat Jun 13 16:17:54 EDT 2020

On Sat, Jun 13, 2020 at 3:58 PM Ivica Bukvic <ico at vt.edu> wrote:
>
> 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.

I'd try commenting out the call to throttle_console_scroll and see how
that affects performance.

-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 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
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev