windows defender issues? & other AV issues?

[Brian Milby]

I've looked into the pref save code and it isn't as bad as I thought.  The
file is saved regularly, but not at the interval that I thought.  It does
have a half second delay which should prevent too many file writes (the
actual save is debounced 500ms in the future, so if another save request
comes in then the write is delayed).  I was thinking that it was saving
much more often.

Interesting on revApplicationOverview.rev since that path isn't where the
stack lives (it is missing "Plugins").  I see 44 references to the stack
name in various places (most in revbackscriptlibrary - 33), but most come
in groups of 3 (if there is a stack... if the mode is not 0... the do
something).


On Mon, Jan 7, 2019 at 11:37 PM Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Curry Kenworthy wrote:
>
>  > Richard:
> ...
>  >> How many devs among us are shipping apps which rely on
>  >> frequent disk saves?
>  >
>  > Not the devs that heed my usual advice and KISS philosophy. :)
>  >
>  > But any system-intensive action performed too often or at the wrong
>  > time during typing, animation, or other activities where lag is
>  > obvious can be an issue on any platform - Mac, Windows, mobile, even
>  > web, even using any language - not just LC.
>  >
>  > Bad coding habits or insufficient caution is just bad, fullstop,
>  > regardless of the context. Good habits and caution are critical, no
>  > matter whether someone is a post-HC hobbyist or a degreed comp sci
>  > engineer. That's why I'm always harping like a broken record about
>  > good habits. :D
>
> Everyone on the LC dev team is either a CS or advanced mathematics
> graduate.  I'm not losing sleep over the prospect that they haven't at
> least thumbed though Knuth.
>
> The Script Editor is in competent hands, and with community involvement
> it only get better.
>
> I'm more interested in those of us who do not hold a doctorate in CS, or
> even when we do what should be considered the "right" thing and still
> find performance impaired.
>
> I haven't finished reading the specs at sqlite.org, but I skimmed enough
> this evening to get the impression that there's a fair bit of
> housekeeping needed to satisfy what we consider read-only operations
> like queries. Some of that housekeeping needs persistence, particularly
> with materializations for pre-evaluation of subqueries, among others.
>
> So using the world's most popular No-One-Ever-Got-Fired-For-Choosing-It
> local storage solution may still not make one immune to the effects of
> this unusual performance hit from Windows Defender.
>
> I haven't benchmarked that specifically, though it would be a good test
> if someone here has time.
>
> But even with flat files, we write data when we need persistence. I
> doubt many stay up late adding routines that write to disk
> unnecessarily. Sometimes it's to flush cache.  Sometimes it's state data
> useful for session restoration.  Sometimes it's the user's document.
>
> And with modern conventions trending toward auto-saving vs the older
> explicit user-driven saves, some of the most well-written apps write to
> disk more frequently than ever before.
>
> I'm less interested in casting judgment on code I haven't read written
> by other people than just making the code I'm responsible for writing
> perform well.
>
> To summarize what we've learned so far:
>
> - Apps write to disk for many legitimate reasons
>
> - Defender's RTP impairs performance of writes
>
> - Even "read" operations on the world's most common local
>    storage format, SQLite, and others, may be affected.
>
> The latter merits testing. And given what we know of the SE, seriously so.
>
> It may be that Prefs plays a key role in timed tasks, but I can't
> imagine if it does that it was the result of an LC team member out of
> things to do.  We write when we need persistence, so I suspect they
> would do no less.
>
> But here's an interesting thing - boot your Linux box and run this:
>
>   strace ./livecodeindy.x86_64 &> strace-log.txt
>
> It's super-annoying to try to scroll though, and no, I haven't read
> every line (I'll leave that for more diligent souls like Mark Wieder,
> who will probably run that when he reads this <g>).
>
> At a quick skim I see evidence of a lot of timers (which we would expect
> given the SE's features), but an interesting thing about file access is
> a lot of lstat and open calls apparently looking for, and not finding,
> the App Overview stack file:
>
> lstat("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev",
>
> 0x7ffc8d185800) = -1 ENOENT (No such file or directory)
> open("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev",
>
> O_RDONLY) = -1 ENOENT (No such file or directory)
>
> That much seems a bug, and I'll add notes to about that to the bug
> report. Since it isn't finding the file it can't write to it, and
> without writes I doubt it's the thing people are seeing when they turn
> RTP on and off.  But worth looking into for the sake of tidiness.
>
>
> Oddly, in my quick skim of the log file I haven't yet seen calls to the
> various SQLite files the IDE uses or the Prefs file, and alas I'm out of
> time on this for tonight...
>
>
>  > Thanks for your test, very nice. My regards.
>
> Happy to one of the many people in this process.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>