After updating the version, the running speed of some projects has become extremely slow

I have noticed that several recent beta versions have been causing some projects to become extremely slow, whereas they used to run at a normal speed. I am not sure what has changed. Are there any friends who have encountered a similar situation?

For instance, the project named ‘shooter’ is available for download on WebRepo, or you can choose to download it directly from the link provided here (if you haven’t installed WebRepo, although I highly recommend that you do). However, the issue with the slow running speed of the ‘shooter’ project did not start with the latest version; it appeared in a previous version.
I am not certain which version it was; I had originally planned to pinpoint the exact issue but was delayed by other matters. Today, after updating the version, I found that it is still running slow. (3.7 MB)

Codea version: 3.10.1(455)

BTW. If you choose to download ‘shooter’ from WebRepo, you will need to manually modify two places:

  1. main.lua line: 2
-- displayMode(FULLSCREEN)
+ viewer.mode = FULLSCREEN
  1. player.lua line: 411
--  local ang = math.atan2(v.y, v.x)
+ local ang = math.atan(v.y, v.x)

@binaryblues - loaded latest version Codea and Shooter, made the mods you suggested and ran Shooter. Did seem a little jerky. Pulled across the parameter window and it fired up loads of error advice, notably that addressing assets with “Documents:Mysprite” isn’t viable now. This error was accumulated to the max then it stops displaying but probably still sees the errors. I think that could be the problem. After looking at the code I saw several sprite(Project:etc…) lines in the code.

P.s. there were other error notes too.

@Bri_G Thank you for the reminder. I also have some doubts that the issue lies with the asset processing prompts. However, these prompts have not affected the project’s running speed in the past, which is why I did not modify them. It seems it is time to start making changes.

In another project, the speed has become intolerably slow. That project also has a large amount of old code for asset processing that needs to be updated.

i had a similar issue in a recent thread. Accessing assets is now considerably slower than before. If you have a loop in which you access the same asset you should access it once outside the loop and save to a variable and then access that variable in the loop. Similarly in the draw you should preload the asset to a variable and refer to that variable in the draw.

@piinthesky @binaryblues - I raised a question recently in the forum asking what was the best way of addressing assets for Codea, whether to use an asset path in a sprite() function call or whether to use readImage() or even a tabled array of addresses. It obviously depends on the number of assets you wish to call on, where they are stored and the frequency that you call them on.

I tend to use a couple of methods namely

Defining a variable like. Pic = asset.documents.canines.alsatian
Or in an array like
dogs = {
…. Etc

That condenses the code, keeps them in a single page so they are easy to edit and reduces code clutter.

What I was trying to find out is is it better to use

Defining a variable like - Pic = readImage( asset.documents.canines.alsatian)
Or in an array like -
dogs = {
Alsatian = readImage(asset. documents.canines.alsatian),
pug = readImage(asset. documents.canines.alsatian),
…. Etc
The latter I would expect to be faster as each image is loaded when defined, but could conceivably gobble up memory.

P.s. I’ve been all the way through Shooter and changed the addressing to update it but ran into a problem with concatenation see below

local slot = asset.save_ .. editor.saveSlot

The Codea editor wouldn’t accept that.

@piinthesky Thank you for the reminder. It seems that everyone has to face this issue. The problem I am facing now is that there is a lot of old code that needs to be modified. For the newly added parts that use assets, I will refer to the experience you have provided to write them.
@Bri_G Thank you for providing the issue localization. I have also seen this piece of code, and the alternative solution I have in mind is as follows:

    local slot = asset .. "save_" .. editor.saveSlot
    print("slot: ", editor.saveSlot, slot)
    local backup = readText(slot)
    print("backup: ", backup)
    self.timers = {}

the log:

slot: 	1	Asset Key: save_1 (path: "/var/mobile/Containers/Data/Application/5EE90784-CAAD-449F-A8BD-B6A9ADF55B72/Documents/ShooterModify.codea/save_1")

But it seems that the readText(slot) return nil


The line should like below:

    local slot = asset .. "save_" .. editor.saveSlot .. ".txt"

Otherwise, Codea will process according to asset.save_1 instead of asset.save_1.txt.

but the log shows the asset key is save_1.txt, I donot know if the asset key should include the extension .txt?

slot: 	1	Asset Key: save_1.txt (path: "/var/mobile/Containers/Data/Application/5EE90784-CAAD-449F-A8BD-B6A9ADF55B72/Documents/ShooterModify.codea/save_1.txt")

This version I have modified almost all the asset line, except the dynamic code. (3.7 MB)

Just a note that you can do viewer.showWarnings = false to disable the warnings for legacy keys

@sim Thank you very much, you have saved at least half of my projects!!!
I am currently trying to identify the cause of the extreme slowness in the other half of my projects, and I hope that I can find it.

@sim the slowdown is no joke though, it’s bad. Like, bad. The following code used to run 200 times instantly:

    function createSphere(x,z,size,type,r,g,b,xv,zv)
        sphere1.model = craft.model.icosphere(size,1)
        sphere1.material = craft.material(asset.builtin.Materials.Specular)

…and in fact it still runs instantly if you comment out the part with the icosphere.

But with that part left in, doing this 200 times takes around 38 seconds. That may not sound like a lot of time, but if you’re looking at a blank screen it’s a lot.

For me the slowness is not from the icosphere line, it is this:

sphere1.material = craft.material(asset.builtin.Materials.Specular)

If possible, you could pass the material into the createSphere function so that you can load it once, outside the loop.

That said, I wonder if optimising from reading asset keys from the builtin libraries might be worthwhile (these are the only ones where we can guarantee no one else is touching the asset file)

Thanks @sim—it actually was materials causing the slowdown, though in a different part of the code that I’d left out for brevity.