Hi Matthew,

Thanks for providing the suggestions.

When using Racket 6.3.0.11 (built on 2016-01-06) and your recommended 
changes
to calling create-embedded-executable, I get a built application that starts
up in the same amount of time as the one built with 6.1.1.  Unfortunately, 
the
memory use while compiling is still high: seems to me to be about the same 
as
for 6.3, but I'm only watching the number in the task manager.  
Incidentally,
because it uses about 3Gb of ram, the build is constantly swapping, making 
it
extremely slow.  The difference in build times is huge (see below).  In both
cases, I had only DrRacket running on a Core i7 w/ 8Gb of Ram:

Welcome to DrRacket, version 6.3.0.11--2016-01-06(4b266f1/a) [3m].
Language: racket; memory limit: 2048 MB.
> (time (build-app))
cpu time: 439953 real time: 442172 gc time: 120471

Welcome to DrRacket, version 6.1.1 [3m].
Language: racket; memory limit: 2048 MB.
> (time (build-app))
cpu time: 174812 real time: 177352 gc time: 77731

On a somewhat related note, there are two additional issues I noticed with 
the executables produced by the Racket compiler (across several Racket 
versions, but also present in the last pre-release build).

First problem is that although the compilation succeeds with no error 
message, the application fails to run with a message like:

link: bad variable linkage;
 reference to a variable that has the wrong procedure or structure-type 
shape
  reference phase level: 0
  variable module: '#%embedded:g498165:sport-charms
  variable phase: 0
  reference in module: '#%embedded:g477831:fmt-util
  in: val->pct-of-max
  errortrace...:
  context...:
   #%embedded:g477831:fmt-util: [running body]
   #%embedded:g473202:al-widgets: [traversing imports]
   #%embedded:g471367:edit-session-summary: [traversing imports]
   #%embedded:g469250:activity-edit: [traversing imports]
   #%embedded:g450111:toplevel: [traversing imports]
   #%embedded:g434256:activity-log-main: [traversing imports]
   run: [traversing imports]
   loop

I can fix this by cleaning the "compiled" folders, but I would expect the 
compiler to either re-build dependencies or flag a compilation error, but 
it does neither.

Second, the resulting application seg-faults, sometimes at startup 
sometimes during importing sport activties.  I have the crash dumps but 
cannot make any sense of them, as I have no PDB's for libracket and I'm not 
familiar with the internals.  If you are interested, I can make them 
available.

Best Regards,
Alex. 

On Friday, January 8, 2016 at 10:50:00 PM UTC+8, mflatt wrote:
>
> The start-up problem is a combination of two things: 
>
>  * Starting with v6.3, the `plot` library is implemented with typed 
>    classes. The compile-time part of typed classes is big and 
>    expensive. 
>
>  * The run-time system is over-eager in forcing compile-time code in 
>    response to a `dynamic-require` of already-compiled code, so that 
>    expensive compile-time part gets run in your generated executable. 
>
> The last bullet has been fixed for the next release, so you could try a 
> snapshot build. (The most recent snapshot build failed on Windows for 
> boring reasons, but the previous build is still available through the 
> "last-success" links.) Unfortunately, I don't have an easy workaround 
> for v6.3. 
>
>
> The change to `plot` also explains why generating an executable takes 
> so much more time and space than before. In that case, the compile-time 
> is needed, so it can't be skipped, but various caches help. There's 
> still room for improvement in the executable-generator so that it 
> doesn't re-expand modules so much, but I'll have to think about it 
> more. 
>
>
> Finally, I think you can avoid some unwanted influence by DrRacket and 
> its debugging mode on the generated executable by wrapping the call 
> to `create-embedding-executable` with 
>
>   (parameterize ([use-compiled-file-paths (list "compiled")]) 
>     ....) 
>
> It's also a good idea to pass 
>
>   #:expand-namespace (make-base-namespace) 
>
> to `create-embedding-executable`. 
>
>
> At Fri, 8 Jan 2016 03:16:13 -0800 (PST), Alex Harsanyi wrote: 
> > I finally got my application [1] to build using Racket 6.3 after working 
> > around the problem with using plot-snip% objects [2].  Unfortunately, 
> now 
> > while building the application, Racket 6.3 uses between 1.5 and 3 Gb of 
> > RAM, while Racket 6.1.1 only used between 0.5 and 0.8 Gb or ram to do 
> the 
> > same thing.  Once built, the application takes about 60 seconds or more 
> to 
> > start up, compared to the version built using Racket 6.1.1 which takes 
> > about 3-5 seconds to start up.  Once it started up, the application is 
> just 
> > as responsive as the previous version, so the problem is only during 
> > startup. 
> > 
> > For reference, I'm using 64bit Racket versions on a Windows machine. 
> > 
> > Could someone provide some starting points for trying to diagnose the 
> cause 
> > of this?   I'm not really familiar with the Racket internals. 
> > 
> > BTW, if anyone wants to build the application using Racket 6.1.1, you 
> have 
> > to drop the last two commits of the master branch, as they contain the 
> > workaround to make the code work in Racket 6.3. 
> > 
> > Thanks, 
> > Alex. 
> > 
> > [1] https://github.com/alex-hhh/ActivityLog2 
> > [2] 
> > 
> https://groups.google.com/forum/#!searchin/racket-dev/plot/racket-dev/wOgQ9gdWq
>  
> > fQ/sRwkfGBMXyIJ 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Racket Developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to [email protected] <javascript:>. 
> > To post to this group, send email to [email protected] 
> <javascript:>. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/racket-dev/47433de9-48b8-44b2-adfd-e4939db539
>  
> > 4a%40googlegroups.com. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-dev/a9439968-ffcf-4a69-9fa0-c50b00ece425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to