Re: [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 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! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Large preferences file and performance
This would not have helped us with the bug Casey found, I don't think. Robby On Thursday, December 2, 2010, Eli Barzilay 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 > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Large preferences file and performance
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
Re: [racket-dev] Refactoring in-vector and friends
Yesterday, Noel Welsh wrote: > If you have objections please let me know -- if I don't hear any > I'll commit tomorrow. Diff is attached. 1. At this level, I think that the costs are very important -- and there's two possible costs here: (a) it adds more files to racket/base which adds some overhead to starting up; (b) more importantly, there is no inlining across module boundaries, which means that such splitting can make things significantly slower. (For example, in racket/private/sort I've made some ugly tricks to make things fast, in a way that would be much harder to do across modules.) 2. Since you refactored code, I prefer seeing two commits -- one for shuffling things around without any changes, and one for adding the new feature. This will make reviewing the change easier, and help if there's problems to debug later on. -- ((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
[racket-dev] Large preferences file and performance
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) My preferences file was enormous because, due to a bug, it had accumulated more than three years of REPL history. I no longer have the ballooned file, but IIRC, it was tens of thousands of expressions, totaling a few MB of text. To help spot issues like this one, Robby and I have added a little "P" indicator near the GC icon that turns on when the preferences file is being saved. If the P flashes rapidly (as it would have when you typed in the find or replace fields) or stays on for a while (as it would have if your preferences file were large), it may indicate a performance problem. The P won't appear at all unless you're running a nightly build or building from git. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Refactoring in-vector and friends
I've read the commit and it looks like a good change. I presume you've re-run the tests and you'll write new tests for the new vector types? Jay On Wed, Dec 1, 2010 at 8:41 AM, Noel Welsh wrote: > Hi all, > > I spent (far too much) time this morning refactoring the definition of > in-vector to expose the building blocks to compose these > macro/functions. After refactoring the code for defining in-vector is: > > (define-:vector-like-gen :vector-gen unsafe-vector-ref) > > (define-in-vector-like in-vector > "vector" vector? vector-length :vector-gen) > > (define-sequence-syntax *in-vector > (lambda () #'in-vector) > (make-in-vector-like #'vector? > #'unsafe-vector-length > #'in-vector > #'unsafe-vector-ref)) > > This could obviously be made smaller but it sufficient to enable reuse > for in-flvector (my goal), in-f64vector etc. In doing so I split > for.rkt into three (I couldn't handle refactoring the 1000+ lines of > for.rkt; I needed something smaller to understand it all). Since this > is a moderately large change I'm looking for comments/objections > before committing. If you have objections please let me know -- if I > don't hear any I'll commit tomorrow. Diff is attached. > > N. > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] OpenMath / SCSCP?
I just heard about OpenMath & SCSCP, open standards (XML-based) for representing algebraic entities and allowing remote procedure calls to a variety of existing commercial and free algebraic solvers, and my first thought was: yikes! Do we have bindings for this? It looks like we don't. Given the apparently XML-based and TCP-based nature of these protocols, it looks like this could be incredibly low-hanging fruit, for us. Is this something that everyone's already heard of? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Behavioral subtyping for editor<%> and its implementing classes
Hi all, While writing contracts for classes in racket/gui, I noticed that the implementations of text% and pasteboard% do not act as behavioral subtypes of editor<%>, which both classes implement. In particular, consider the do-copy method from editor<%>. Its contract looks like this: (send an-editor do-copy) → void? http://pre.racket-lang.org/docs/html/gui/editor___.html?q=do-copy#(meth._(((lib._mred/main..rkt)._editor~3c~25~3e)._do-copy)) However, the implementations have the following contracts: (send a-text do-copy start end time extend?) → void? http://pre.racket-lang.org/docs/html/gui/text_.html?q=do-copy#(meth._(((lib._mred/main..rkt)._text~25)._do-copy)) and (send a-pasteboard do-copy time extend?) → void? http://pre.racket-lang.org/docs/html/gui/pasteboard_.html?q=do-copy#(meth._(((lib._mred/main..rkt)._pasteboard~25)._do-copy)) That is, do-copy in editor<%> has no mandatory arguments, do-copy in text% has four mandatory arguments, and do-copy in pasteboard% has two mandatory arguments. Thus, the do-copy methods in text% and pasteboard% do not implement the editor<%> interface (in the behavioral subtyping sense) nor do they implement a common interface despite claiming to. There are several other examples of this issue in the same classes. (see do-paste, paste-x-selection, etc.) Is there a design rationale for this? Is this method not meant to implement a common interface? Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Fwd: [plt-edu] Internal defines in learning languages?
Begin forwarded message: Shriram wrote: > > And the syntax of local IS a problem. > (dev-only) +1 John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
