Saving takes over 20 minutes

[DavJans]

I recently upgraded my computer to a much better one and unfortunately Windows 10. It used to take a while like 1 to 2 minutes to save on my old computer, but now it takes well over 20 minutes. Any ideas to try to get it back to normal?

Windows 10 Pro x64
LC version 9.5.0 | Build 15503

[richmond62]

What has that to do with LiveCode?

[bogs]

Maybe DavJans is takling about saving a stack from the IDE ?

I'm actually a little curious myself as to the specifics

Please DavJans, feel free to elaborate.

[dunbarx]

Dave(?) certainly means a LC stack.

What happens if you try to save a brand new stack with nothing on it?

Craig

[bogs]

Well, I was also thinking he could mean saving a standalone from the IDE, there have been plenty of posts about that taking inordinately long amounts of time.

[DavJans]

Yes, saving the stack before saving as standalone application.

I figured it out. It's because i was saving to a network location. Saves in like 15 seconds when I made a local copy.

[dunbarx]

Saves in like 15 seconds when I made a local copy.

How big is that stack? Mine take 1/2 second.

Craig

[mrcoollion]

Well, I was also thinking he could mean saving a standalone from the IDE, there have been plenty of posts about that taking inordinately long amounts of time.

I also have noticed a huge increase in saving time in the IDE as of version LC 9.6 dp1 .. Did anyone post this as a bug?

regards,

Paul

[bogs]

Well, what I was referring to isn't a bug, per se, and has been around since roughly v1.x., I don't think Mc had an automated build system (aside from RG's plugin).

The posts where someone is referring to creating a standalone taking a long time is (usually) related to not manually picking out inclusions, but instead relying on the IDE to note inclusions. My understanding is that this is not unexpected behavior, or related to the latest series of IDEs, but has been ongoing since automating inclusions was developed.

Letting the IDE pick up inclusions works fine for small projects, or even larger medium projects using the standard language patterns as far as I can tell. When you get into larger projects, though, or non standard language usage, the IDE will sometimes miss inclusions or other things will go wrong. How you could devise a test to find just *where* or *what* the IDE isn't detecting correctly though is beyond my level of ability. I've also never had it happen to me personally, I suspect many others have never had it happen either.

Aside from that, the later IDEs (say, post 7.x) are a tad slower than the earlier IDEs due to the amount of changes in them that have not (as of yet) been optimized. Things like the options in the script editor (live errors, bracket highlighting, etc), and which OS you are using contribute to other discussions of 'slowness', but I was referring strictly to the first scenario which is pretty well known and threaded throughout this forum.

[dunbarx]

Ah,

"Saving" a standalone. I thought it was just "saving".

I always explicitly set inclusions, and the build (not save) process is much faster.

Craig

[bogs]

See, I think this is what causes all the confusion ...

Build...Save...Huhhh?

[DavJans]

The stack is 30,437 KB. The part that was taking over 20 minutes was saving before the building actually started. I used a stopwatch when saving and it takes 21 and a half seconds to save. Is that unusual for this size stack? I started the stack 5 to 6 years ago in i don't even remember what version. 6 something I think. should I start from a brand new stack when upgrading LC or does it not matter? and yes, the Names Dave

[bogs]

Well, while you shouldn't have to start working on a new stack for each new version of Lc, I would suggest renaming the original stack or folder and using a copy to work with in each new IDE going forward.

I.e. your original stack is in folder A, you open it in a new version of Lc and save it to folder B, rinse / repeat through Z (although really, if you live long enough to work in 26 versions of the IDE, get a lotto ticket because you are probably due to retire soon )

As to taking 20+ seconds to save, is the 30+k KB stack that size from controls, or code? If it is mostly from code, it might be time to go through it and prune (also known as refactoring) the code.

If it has a lot of objects, I still can't see it being very large in size, this stack has every object from the tool palette on it (minus widgets) and comes in at a svelte 18000 bytes, for instance.

1.21 GIGAWATTS ~!?!?!

For objects / cards / stacks alone to make up that size would take 1666.66 stacks with 1 card each with all those controls. Somehow, I don't think that is happening for you (my hats off to you if it is though )

[jacque]

I also wonder what's making the stack so large. Do you have a lot of imported images? If so, consider including the images as separate files and load them by reference instead. That may cut down on the build time. It's also important to choose inclusions manually. Usually long build times are because LC has to scan every line of every script looking for inclusions if you've chosen automatic inclusions.

I have a small stack with almost no embedded images and it takes about a minute and a half to build. Another stack with a huge number of libraries, imported images, substacks and other assets takes 7 minutes to build.

[samuel.vannesteBUSGvXT]

A quick tip : that just happened to colleague of mine after we changed his computer.

The project's folder was one saved by OneDrive entreprise. The project was large. LC wasn't allowed to finish the saving operation until the previous version of the stack was saved by OneDrive.

Perhaps the case here.