Re: [racket-users] Reducing Program Startup Time
On Monday, December 5, 2016 at 2:51:26 PM UTC-8, Dan Liebgold wrote: > Ok, those tests aren't particularly illumating (at least they were easy!) > > Is your Racket distribution on a local drive? Network performance can make a > big difference. > The Racket distribution I'm using is on my local drive. I'm beginning to think that this is just how things are with regard to the current state of Racket. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Reducing Program Startup Time
Ok, those tests aren't particularly illumating (at least they were easy!) Is your Racket distribution on a local drive? Network performance can make a big difference. We've also found that the minimal Racket distribution can be quite a bit quicker when pulling in packages outside the main collects directory there's racket code that enumerates files and the main distribution installs thousands of files you may not need. Even local SSD file systems have a noticeable lag doing that. On Monday, December 5, 2016 at 2:25:24 PM UTC-8, Lehi Toskin wrote: > These first two tests are with the lazy-require code. > > If I add '-c': > $ time racket -c -- main.rkt -V > Ivy 1.2 > > real 2m17.134s > user 2m13.646s > sys 0m2.394s > > With '-j': > $ time racket -j -- main.rkt -V > Ivy 1.2 > > real 0m4.369s > user 0m2.851s > sys 0m0.155s > > > These next two tests are with the usual require. > > With '-c': > $ time racket -c -- main.rkt -V > Ivy 1.2 > > real 3m58.587s > user 3m53.370s > sys 0m5.080s > > With '-j': > $ time racket -j -- main.rkt -V > Ivy 1.2 > > real 0m2.645s > user 0m2.526s > sys 0m0.115s -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Reducing Program Startup Time
On Monday, December 5, 2016 at 12:08:12 PM UTC-8, Dan Liebgold wrote: > Are you sure you have up to date .zo files for all your .rkt files? > > How's the timing if you add '-c' to your Racket commandline? How about '-j'? > These first two tests are with the lazy-require code. If I add '-c': $ time racket -c -- main.rkt -V Ivy 1.2 real2m17.134s user2m13.646s sys 0m2.394s With '-j': $ time racket -j -- main.rkt -V Ivy 1.2 real0m4.369s user0m2.851s sys 0m0.155s These next two tests are with the usual require. With '-c': $ time racket -c -- main.rkt -V Ivy 1.2 real3m58.587s user3m53.370s sys 0m5.080s With '-j': $ time racket -j -- main.rkt -V Ivy 1.2 real0m2.645s user0m2.526s sys 0m0.115s -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Reducing Program Startup Time
Are you sure you have up to date .zo files for all your .rkt files? How's the timing if you add '-c' to your Racket commandline? How about '-j'? On Sunday, December 4, 2016 at 4:11:51 PM UTC-8, Lehi Toskin wrote: > ... -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] errortrace requires 10x time and memory for the program to compile
I just tried that: unfortunately, this stack trace does not seem to be able to cross the boundary of dynamically required module. What I see in (continuation-mark-set->context (current-continuation-marks)) are just lines in the "main" Racket module, and no lines that belong to the non-sexp module or deeper. And (continuation-mark-set->context (exn-continuation-marks e)) do cross the boundary, but show only some deeper lines in deeper modules, not in the "top" dynamically required module. Best regards, Dmitry -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] errortrace requires 10x time and memory for the program to compile
Matthew, Question 1: A factor of 10 is on the high side, but not unusual at the moment. There's a pending issue of making sure that `for` loops or other things are not needlessly instrumented, since they're only part of the expansion instead of the original code. We haven't gotten back to that, but I bet it would help with your program. Question 2: No, unfortunately. OK, got it. Question 3: If the built-in, approximate stack trace is good enough, you can get it with (continuation-mark-set->context (current-continuation-marks)) I just tried that: unfortunately, this stack trace does not seem to be able to cross the boundary of dynamically required module. Or, to be precise, the module that is required via (require-input-port) -- the function that you kindly wrote for me three years ago: https://lists.racket-lang.org/users/archive/2013-September/059449.html What I see in (continuation-mark-set->context (current-continuation-marks)) are just lines in the "main" Racket module, and no lines that belong to the non-sexp module or deeper. Actually, all I need is the line number of the non-sexp file where the error originated from. I guess, under these circumstances, I should try and make my own continuation marks in the parser/compiler. Best regards, Dmitry -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] errortrace requires 10x time and memory for the program to compile
Question 1: A factor of 10 is on the high side, but not unusual at the moment. There's a pending issue of making sure that `for` loops or other things are not needlessly instrumented, since they're only part of the expansion instead of the original code. We haven't gotten back to that, but I bet it would help with your program. Question 2: No, unfortunately. Question 3: If the built-in, approximate stack trace is good enough, you can get it with (continuation-mark-set->context (current-continuation-marks)) At Mon, 5 Dec 2016 19:56:07 +0300, Dmitry Pavlov wrote: > Hello, > > I have a program that takes 17 seconds and ~260 MB of memory. > If I use errortrace on it, the numbers grow about tenfold: 150 seconds and > 2600+ MB. > > That is just compilation; in the runtime the program does almost nothing and > terminates quickly. > I know little about how errortrace works and ask for help. > My understanding of the problem is shaped into three questions. > > Question 1. Is it normal for errortrace? > > Note 1: I am using errortrace just for getting the stack trace of a runtime > error: > > (with-handlers >((exn:fail? > (lambda (e) >(for ((stack-elem (continuation-mark-set->list > (exn-continuation-marks e) errortrace-key))) > .. > > > Note 2: The program which stack trace I am interested in is require-d > dynamically, and is actually written in non-lispy language. > errortrace does a great job in planting its continuation marks > into syntax objects that are generated by the parser and > the compiler for that language. > > > Question 2: Is there an option for errortrace to reduce its time and memory > consumption and still provide the continuation marks for stack trace? > I tried (profiling-record-enabled #f), it did not help. > > Question 3: Is there another way to programmatically get a stack trace for a > dynamically loaded program? Am I using a sledgehammer to crack a nut? > > > Best regards, > > Dmitry > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] errortrace requires 10x time and memory for the program to compile
Hello, I have a program that takes 17 seconds and ~260 MB of memory. If I use errortrace on it, the numbers grow about tenfold: 150 seconds and 2600+ MB. That is just compilation; in the runtime the program does almost nothing and terminates quickly. I know little about how errortrace works and ask for help. My understanding of the problem is shaped into three questions. Question 1. Is it normal for errortrace? Note 1: I am using errortrace just for getting the stack trace of a runtime error: (with-handlers ((exn:fail? (lambda (e) (for ((stack-elem (continuation-mark-set->list (exn-continuation-marks e) errortrace-key))) .. Note 2: The program which stack trace I am interested in is require-d dynamically, and is actually written in non-lispy language. errortrace does a great job in planting its continuation marks into syntax objects that are generated by the parser and the compiler for that language. Question 2: Is there an option for errortrace to reduce its time and memory consumption and still provide the continuation marks for stack trace? I tried (profiling-record-enabled #f), it did not help. Question 3: Is there another way to programmatically get a stack trace for a dynamically loaded program? Am I using a sledgehammer to crack a nut? Best regards, Dmitry -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Call for Participation: BOB 2017 (February 24, Berlin)
BOB has a strong focus on functional programming - Racket developers very welcome! BOB 2017 Conference "What happens if we simply use what's best?" February 24, 2017 Berlin http://bobkonf.de/2017/ Program: http://bobkonf.de/2017/program.html Registration: http://bobkonf.de/2017/registration.html BOB is the conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experiences. The program features 14 talks and 8 tutorials on current topics: http://bobkonf.de/2017/program.html The subject range of talks includes functional programming, advanced front-end development, and sophisticated uses of types. The tutorials feature introductions to Haskell, Swift, PureScript, React, QuickCheck, Agda, CRDTs and Servant. John Hughes will give the keynote talk. Registration is open online: http://bobkonf.de/2017/registration.html NOTE: The early-bird rates expire on January 23, 2017! BOB cooperates with the :clojured conference on the following day. There is a registration discount available for participants of both events. http://www.clojured.de/ -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Animation-problem
My pleasure. Good on you for doing the exercise. Here's a slightly modified version that: - removes the use of set!: it's cleaner "functional" style to avoid mutation where possible - illustrates the use of match-define to unpack world - other small tweaks and tricks Dan #lang racket (require 2htdp/universe) (require 2htdp/image) (struct world (foreground background count)) (define (random-color) (make-color (random 255) (random 255) (random 255))) (define (next-state state) (world (random-color) (random-color) (add1 (world-count state (define (SUPER state) (match-define (world fg bg n) state) (overlay/align 'left 'top (text (~a n) 30 "gray") (overlay (text "SUPER" 105 fg) (circle 200 "solid" bg (big-bang (world (random-color) (random-color) 0) (on-tick next-state 0.3) (to-draw SUPER)) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Animation-problem
Thank you Dan, that was very helpful! I haven't used that function big-bang but it seems quite simple. I also add that counter what you suggested. It take some time to figure out how I convert that counter's value to image. -- #lang racket (require 2htdp/universe) (require 2htdp/image) (struct world (foreground background count) ) (define counter 0) (define (random-color) (make-color (random 255) (random 255) (random 255))) (define (random-state current) (world (random-color) (random-color) (set! counter (add1 counter (define (SUPER state) (overlay/offset (text (number->string counter) 30 "black") 160 180 (overlay (text "SUPER" 105 (world-foreground state)) (circle 200 "solid" (world-background state))) )) (big-bang (random-state null) (on-tick random-state 0.3) ; change the image every 0.3 seconds (to-draw SUPER)) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
