Would 2 scripts be better than one?

If I did

when green flag clicked
code :: grey

would it be faster to do

when green flag clicked
code 1 :: grey

when green flag clicked
code 2 :: grey

Scripts don't run in separate threads, so your examples will be equally fast – in fact, the one with a single script would probably be very slightly faster because it doesn't have to run two scripts every frame.

Scratch implements multithreading, so at any one instant only one script is really busy, and the others wait. So it can't make your project faster because that would require different processor cores to simultaneously run different scripts. (Thread switches only occur at particular points in scripts/under particular circumstances so as to prevent Scratchers from creating race conditions.)

If you're interested in concurrency and processing power, I would highly recommend _nix's profile Their newest 5 projects all investigate how scratch handles lag, and how to do tasks faster.

Depending on what code 1 and code 2 are, and how you run them together in code, either scenario could be faster.

In general, however, the fastest solution involves custom blocks with “run without screen refresh” checked. Running the scripts without screen refresh makes Scratch run the scripts as quickly as it can. If you don't use run without screen refresh, Scratch will often slow things down and limit loops to running 30 times per second.

Note that if you use no screen refresh wrong, it could cause extreme lag. When a no refresh block is running, Scratch doesn't update the screen. If something inside a no refresh block takes a long time to finish, it could severely impact your framerate.

define No Refresh 1
forever // Bad, will cause Scratch to run at 2 fps
code ::grey
end

define No Refresh 2
code ::grey

forever // Better
No Refresh 2
end

imfh wrote:

Depending on what code 1 and code 2 are, and how you run them together in code, either scenario could be faster.

In general, however, the fastest solution involves custom blocks with “run without screen refresh” checked. Running the scripts without screen refresh makes Scratch run the scripts as quickly as it can. If you don't use run without screen refresh, Scratch will often slow things down and limit loops to running 30 times per second.

Note that if you use no screen refresh wrong, it could cause extreme lag. When a no refresh block is running, Scratch doesn't update the screen. If something inside a no refresh block takes a long time to finish, it could severely impact your framerate.

define No Refresh 1
forever // Bad, will cause Scratch to run at 2 fps
code ::grey
end

define No Refresh 2
code ::grey

forever // Better
No Refresh 2
end

I always do that…

Spentine wrote:

imfh wrote:

Depending on what code 1 and code 2 are, and how you run them together in code, either scenario could be faster.

In general, however, the fastest solution involves custom blocks with “run without screen refresh” checked. Running the scripts without screen refresh makes Scratch run the scripts as quickly as it can. If you don't use run without screen refresh, Scratch will often slow things down and limit loops to running 30 times per second.

Note that if you use no screen refresh wrong, it could cause extreme lag. When a no refresh block is running, Scratch doesn't update the screen. If something inside a no refresh block takes a long time to finish, it could severely impact your framerate.

-snip-

I always do that…

Then you'll probably be better off running them as a single script, like @Maximouse said.

imfh wrote:

Spentine wrote:

imfh wrote:

Depending on what code 1 and code 2 are, and how you run them together in code, either scenario could be faster.

In general, however, the fastest solution involves custom blocks with “run without screen refresh” checked. Running the scripts without screen refresh makes Scratch run the scripts as quickly as it can. If you don't use run without screen refresh, Scratch will often slow things down and limit loops to running 30 times per second.

Note that if you use no screen refresh wrong, it could cause extreme lag. When a no refresh block is running, Scratch doesn't update the screen. If something inside a no refresh block takes a long time to finish, it could severely impact your framerate.

-snip-

I always do that…

Then you'll probably be better off running them as a single script, like @Maximouse said.

ok

You can always use

wait (0) secs

to force Scratch to yield in a script that has refresh disabled.

9pfs wrote:

You can always use

wait (0) secs

to force Scratch to yield in a script that has refresh disabled.

Everybody knows that. Do you even know what multithreading is?

Spentine wrote:

9pfs wrote:

You can always use

wait (0) secs

to force Scratch to yield in a script that has refresh disabled.

Everybody knows that. Do you even know what multithreading is?

Yes, it yields, so it may cause a thread switch. (And potential race conditions if you share variables between scripts.)

Why wouldn't scratch use multithreading on sprite clones

Pedantic answer: JavaScript is a single-threaded language, and because Scratch is implemented with JavaScript, it cannot provide true multithreading.

Although, Scratch can emulate multithreading by using callbacks, so running two scripts (I think) just sends each script off into a seperate callback, not a thread. Once each script is in its own callback, Scratch just executes code synchronously statement-by-statement.

ajskateboarder wrote:

Pedantic answer: JavaScript is a single-threaded language, and because Scratch is implemented with JavaScript, it cannot provide true multithreading.

javascript can do multithreading btw

ajskateboarder wrote:

Although, Scratch can emulate multithreading by using callbacks, so running two scripts (I think) just sends each script off into a seperate callback, not a thread. Once each script is in its own callback, Scratch just executes code synchronously statement-by-statement.

That's not really how it works… my understanding is currently running threads are stored in an array, annd the sequencer loops through this array and steps each thread until it yields control to another thread. Callbacks have no part to play in this as far as I can tell, although you are correct in that threads are executed synchronously statement-by-statement.

Alright, so from the answers I heard I will assume multithreading code in Scratch is pointless.

I find this distinction useful:
Concurrency = two processes running together in some way
Parallelism = two processes running exactly simultaneously

Scratch is concurrent because you can run several scripts at once, but it's not parallel because Scratch runs one script until it yields, then the next script, etc. every tick.

For your example, the one script will be slightly faster because Scratch doesn't need to switch between scripts, but overall it doesn't really matter.

Scratch supports concurrency, but not multithreading. While it can run two scripts in parallel, only one processor is running it.

If a script for rendering and another script for computing was running in parallel, Scratch doesn't request 2 CPUs from the user's PC, therefore, only being concurrent and not multithreaded.

I'll close the topic now.