From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2001:558:fe21:29:69:252:207:36; helo=resqmta-ch2-04v.sys.comcast.net; envelope-from=eklhad@comcast.net; receiver= Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 7C9487A50C for ; Fri, 11 Aug 2017 02:50:23 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id g6aydLZrMuShVg6b1dnT5x; Fri, 11 Aug 2017 09:51:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1502445071; bh=nsEaB44lNAvhy6lZTn9Nxmp+WudFhy1Hi4StPrZF6LA=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=PshqJmxwV2nblQEay1w414KFYOyRsqwTw+7skAJnfmfx/NyhNii2bfLW1+osgW+5b pAaHw8l3dlaneroi2OCRUuH7IH7A/TrivVv/Xf9AZZTUdLMaJEeJ/ZTPuZrznYDDZ+ 0f4oONPACac5BakxCDmjcoZrSj2tJrVqBXe31AF+/nRYykklMuURKQykcgnMYQSe3O EYig7PJFBvMfXVUX9fQY2g0GLxZH/DBsecyRTJau+E1ZaFGp2nWm1CsMmuiRC8qw1o nBcigCFomeDfLFgZ1ixuWn+zknAnsHXY5t2VWsuCR/Phvrjx/Twpn2ZqXg5mPK4X/k 25jHnusMdiObQ== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-15v.sys.comcast.net with SMTP id g6b0dDnXYsxNeg6b1d1Bn4; Fri, 11 Aug 2017 09:51:11 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20170622224940.eklhad@comcast.net> <20170811074654.GB15710@odin> User-Agent: edbrowse/3.7.0+ Date: Fri, 11 Aug 2017 05:51:10 -0400 Message-ID: <20170711055110.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-085527 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBlp1fNMQCQdABdjU1HLJrTu/8j6UC32YohTQqR5t+c26RYcT+PNeX0cEX4qkdrBEx8gdebF05M4fxUnz/a8Ss4vl/tZyjxFXEamxS9O8ZBbRSG+WASv ll3CrtVEzX3bOEeHmtFsCiHCls+ML0NXGOdEMbahw0mCra5Jmi1PvnnT Subject: [Edbrowse-dev] JS1 X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 09:50:23 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-085527 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Having not seen the patch, it sounds like you changed the "scheduler" = to be more "round robin" between input and timers, and that's fine. That part is ok but I am still concerned about rapid fire timers. > Since some of these timers aren't for visual effects (polling, = checking Is there really a site that *needs* timers faster than 500ms for = nonvisual purposes? Kevin you've combed through the acid tests, is this a concern? 1. I suppose I have a general concern about resources, edbrowse will = never be optimized the way chrome is, it's already slow, if we have a = dozen such sites up with these timers, some of them pushed onto the = stack so we don't even see them, and they're all running at this rapid = rate, I can picture the load average climbing up above 3. 2. I live and die by db5. I couldn't have gotten this far debugging = without db5. Each timer produces a lot of debugging output. Some of this is overhead = just to run the timer. Did the user change one of the input fields, and do we have to push = that change down to the js world before we run the js timer, and when = we get back is there stuff we have to do? Trust me it makes a lot of output. If that flies every ten seconds it's prohibitive on the screen, and = even when redirected into a debug file, the file is huge in a matter of = a second. And it might take several seconds to set up the condition I'm trying to = debug. Then I have to slog through a 100 megabyte file to find the problem. So that's a concern to me. I imagine you could let timers fly at db2 or less, and cap them at = 600ms for db3 or higher (my cap is 600ms across the board today), but = that means db2 and db3 run differently and that has its own concerns. 3. Edbrowse doesn't garbage collect at all. html tags keep accumulating. Look at www.eklhad.net/async. It updates the page once a second via = innerHTML. On the js side, new objects are created, and the old ones go away via = gc. On the edbrowse side, new tags are created, and the old ones are marked = dead when js removes the corresponding objects, thanks to Dominique's = clever trick, but the old tags don't go away, they just sit there dead. This is something we may need to address at some point, it's just not = there today. So memory will grow very quickly at 10ms, and not just memory, because = a lot of the code simply scans through those tags linearly, so edbrowse = will bog down very quickly. Knuth would frown on a lot of this code, but it is what it is. I don't think we can or should run high timers until this issue is = addressed. Push the round robin if you like, but I wouldn't ratchet the timers up = to high just yet, or maybe make the cap a global variable that we can = change in various circumstances, or set in the config file, or = otherwise have some control over. Perhaps the foreground window runs fast and all other edbrowse windows = are throttled, or based on debug level, or slow down after we have 5000 = tags, IDK. Thanks for looking into this. Karl Dahlke --nextpart-eb-085527--