loading executables into memory

[dthompson16]

Just a hypothetical question now that some of my AMS applications (compressed executables) are getting quite large. So far no one has squawked about having problems loading them, but what would happen if the size of the app we create with AMS exceeds the memory on the user's machine? Would there be some kind of "could not load" message, or could this even happen at all? That is, would a very large AMS application that exceeds the size of the memory on the user's machine run anyway (by "paging" parts of the application in and out of memory, perhaps?)?

[Intrigued]

I want to hazard a guess before the I.R. crew chime in with an official explanation.

It seems that the H.D. would be utilized via the, ie., Page File. Much like when another program needs more memory (read: R.A.M.) than is available.

[Worm]

A compressed executable extracts all the files to the temp folder of the PC. Then spawns the autorun.exe, the files are not extracted to memory. You could possibly run into a problem if there is low hard drive space.

[dthompson16]

If I'm understanding both of you guys correctly, the limiting factor on the size of an executable would only be space on the user's HD and not the size of the user's RAM. Theoretically at least, then, the size of an executable wouldn't matter. Is this right?

[eric_darling]

The AMS runtime itself doesn't change from its set physical size that I'm aware of. It's the other external media that's making your compressed executable larger.

However, that doesn't mean RAM requirements won't fluctuate based on the media utilized in a given project. I'm sure an IR dev team member can help make this more resoundingly clear.

[Intrigued]

I disagree with Worm.

Try loading in this order, compressed .exe's created in AMS 5.

1. Blank project (then Ctrl-Alt-Del and check the RAM usage)

2. Small (1MB or less) video (then Ctrl-Alt-Del and check the RAM usage)

finally...

3. Have a larger and longer length video play (then Ctrl-Alt-Del and check the RAM usage)

My RAM usage went from 3MB to over 28MB!

[Worm]

I never said having a larger project wouldn't take more RAM, what I said was that after the initial extraction, there should be no difference in RAM usage between a self extracting and normal project.

I've not run any tests to prove this, but I like my theory and will stick with it.

[eric_darling]

Betting against the Worm is always a risky move! ;)

Actually, I think what Worm and I are saying are essentially the same thing. The RAM requirements for a project aren't really affected by whether or not the project was published as a compressed executable, which goes to the original inquiry in this thread.

[Corey]

Betting against the Worm is always a risky move!

Agreed. :)

[Ted Sullivan]

Indeed, whether you use the "normal" or "single-executable" style of publishing, will not change the amount of memory being used. Although, having too large of a "single-executable" will increase the start-up time as it decompresses information to the hard drive.

So, on to memory usage...

Go to Project > Window Settings and click on the Advanced tab. You'll see a whole section about "Memory Management". The default is "automatic" and that will work quite well for just about any project. It basically looks at how many pages are in your project and then automatically chooses either Maximize Speed or Conserve Memory for you.

Maximize Speed
Each page's data will be cached in memory after it's initial display. If any of these pages are viewed again, loading time is reduced, however memory usage will increase on the end user's system throughout the application.

Conserve Memory
Do not cache page data in memory. Each page's data will be reloaded from disk or drive, minimizing memory usage on the end user's system.

You can experiment with these two options and see what works best for your project. Basically, with the first option as each page is loaded it keeps it in memory. If your project is really large (bigger than available memory), it will rely on Windows memory paging to allocate virtual memory space from the hard drive and basically negate any speed benefit at that point.

The conserve memory option just loads each page as it is needed and frees the memory when a new page is shown. This allows projects of basically unlimited size to function correctly and consistently.

And there you have it!

[Worm]

Thanks Ted, I couldn't sleep at all last night ;)

[Intrigued]

Worm, I misinterpreted your initial post wrong! (pt. Worm) :D

It more closely answered the question put forth by the thread-start post.

Taking into account what I put forth though would be wise, well, or so it would seem.

So, while my initial comment will not change any case-law anytime soon; (har har), I will stand by my comment... even if it is disjointed a bit from the main question put to hand. Or, so my lawyer advises.

[Derek]

Here ends the lesson! ;)