[racket-dev] Large preferences file and performance

50 minutes ago, Robby Findler wrote:
> This would not have helped us with the bug Casey found, I don't think.

Well, not the bug itself (having a huge preference file that is saved
on every keypress), but it would have made life easier since a quick
sequence of keypresses would have only one write at the end, usually
when it would be idle anyway.

(IOW, it would make the other two problems harder to find, which is
exactly the desired effect of less writing.)


> On Thursday, December 2, 2010, Eli Barzilay <eli at barzilay.org> wrote:
> > 20 minutes ago, Casey Klein wrote:
> >> I just pushed a fix for a bug that made DrRacket extremely sluggish
> >> on my laptop. Most everything was slow, but typing in the find and
> >> replace fields was particularly bad -- each character would take
> >> about a second to appear on screen.
> >>
> >> The problem turned out to be that my framework preferences file was
> >> enormous, a problem since DrRacket saves your preferences very
> >> frequently. In particular, it saved them on each keystroke in the
> >> find and replace fields. (But no more. See http://bit.ly/eQmhOH)
> >> [...]
> >
> > Something that I have said in the past a few times: IMO, it would be
> > better to have an indirection layer when writing the preferences --
> > most of the "transient" changes (like ones that happen after every
> > keystroke or a result of moving or resizing the windows) could go
> > through with a timer so that there are no such frequent writes,
> > instead, they'd be lumped in less frequent writes.  Non-transient
> > changes (eg, changing preferences) could still be done immediately, so
> > there's no consistency issues with such changes.
> >
> > IIRC, Robby argued against this since he was worried about things not
> > getting written -- I think that splitting things to these two kinds of
> > changes would make this a non-issue -- for example, if DrRacket
> > crashes while you're moving a window you won't care about losing the
> > last changes.  I think that another issue was the level that this is
> > done -- and since the framework has an indirection anyway, it would be
> > natural to do this at that level rather than in the lower one.
> >
> > --
> >           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
> >                     http://barzilay.org/                   Maze is Life!
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://lists.racket-lang.org/listinfo/dev
> >

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!