YOUR ACCOUNT

Home > Forums > Scripting > 

Script Optimization Tricks

Active Topics Search
Login or Register to post new topics or replies
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
If you're concerned about the performance of your script, check out this page:
http://lua-users.org/wiki/OptimisationCodingTips

..Good stuff in there.

Please add your own findings to this thread, and feel free to post optimization problems smile:)
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: June 16, 2010 3:30 am   Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
Quote
Locals are faster than globals. See OptimisingUsingLocalVariables.


That's a good argument in favor of local which I used to dislike for aesthetic reasons.
Posted: June 16, 2010 5:05 am   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Indeed! Also moving functions inside a main function (e.g. get_sample) seem to have impact. Dunno why that is, but its probably something related (less indexing or something)

Another thing I noticed is that the evaluation of conditionals with else parts can be slower than simply preinitializing the variable with the else part:

j = 0
if (i == true) then
j = 1
end

instead of

if (i == true) then
j = 1
else
j = 0
end

but of course it depends on the actual case: if the else part is a heavy piece of code performancewise, its not worth it.
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: June 16, 2010 5:40 am   Details E-Mail
Darrell Plank
Posts: 42
Filters: 4
In assembler (well, at least the ancient 8086/88 assembler I used to write in), jumping takes longer than straight line code. If you write (the assembler equivalent of)

j = 0
if (i == true) then
j = 1
end

then you are making no jumps if i== true and even though you're setting j twice, that's way trumped by not making a jump and therefore faster. In the other example you're always making a jump.

This performance thing had to do with the pipeline in the old xx86 processors and unless LUA compiles directly to assembly (dunno, but I doubt it), then this isn't the direct reason but it may still be that in LUA jumps are expensive for whatever reason.
Darrell
Posted: July 1, 2010 12:40 am   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
This page show some interesting tests - I learned a few new tricks there smile:)

http://trac.caspring.org/wiki/LuaPerformance
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: July 10, 2010 7:31 am   Details E-Mail
Totte
Ãœbernerd

Posts: 1460
Filters: 107
Very good info Sphinx!
- I never expected the Spanish inquisition
Posted: July 10, 2010 11:23 am   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
I started a new wiki page on the subject. Check it out and feel free to add stuff to it smile:)

Edit: The article covers very basic scripting concepts, so its a good read for scripting beginners smile:)
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: November 15, 2010 5:55 am   Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
Quote
Sphinx. wrote:
I started a new wiki page on the subject. Check it out and feel free to add stuff to it smile:)


Just wanted to say that this is an excellent article!
Posted: November 24, 2010 2:16 pm   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Thanks Vlad, I will be completing it soon - I'll probably split it up, so the examples are on a dedicated page.

If Egret or one of the programmers could take a quick look at it when they have a minute or two, that would be great - I'm not 100% sure about all the conclusions / assumptions I make.

Btw have you considered LuaJIT? I recall there was some problem with terminating endless loops, but perhaps you could make it optional (in the script settings add some sort of "Optimized (Unsafe)" option)
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: November 25, 2010 2:18 am   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Alright, the Scripting Tips and Tricks article is complete (for now).

It would be great with some feedback on it, specially regarding clarity: if certain parts need additional explanations etc, let me know.

Also if there are common operations you'd like to see covered, let me know.
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: December 6, 2010 5:24 am   Details E-Mail
James
James
Posts: 676
Filters: 46
If i have 4 black and white gradients i noticed replacing them with scripted versions makes the render time go from 5.4 to about 10+ for some reason.

For the gradient though it is just -

function prepare()
end;
function get_sample(x, y)
return x, x, x, 1
end;

So i am wondering if there is even a good way to optimize that type of code since it is so simple. Maybe the default nodes are just a great deal more faster than Lua, since the default node has other controls as part of it though i was originally guessing the Lua version would be more optimized.
Posted: May 13, 2011 1:44 pm   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Quote
Sphinx wrote "James wrote:" because direct Quote function does not work in Chrome
If i have 4 black and white gradients i noticed replacing them with scripted versions makes the render time go from 5.4 to about 10+ for some reason.


I did some experiments regarding just that. You can read about it here:
http://www.filterforge.com/wiki/index..._script.22

Indeed there is a way to "optimize" that type of very simple scripts: don't script smile;)
The rule of thumb is simple: if you can easily construct the script equivalent just using a few native FF components, then its a better choice.
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: May 17, 2011 1:44 am   Details E-Mail
James
James
Posts: 676
Filters: 46
Thanks, I was expecting that would be the answer.

Hopefully in the future this might change though, it would be great if the lua scripting could be made a bit faster so things like the simple gradient code i posted would rival or be faster than the standard node. smile:)

I just had a interesting idea -

http://www.filterforge.com/forum/read...ssage93321
Posted: May 17, 2011 10:19 am   Details E-Mail
inujima

Posts: 176
Filters: 26
This document is helpful as well.

http://www.lua.org/gems/sample.pdf
Posted: May 17, 2012 2:02 pm   Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1750
Filters: 39
Good one Inujima!

Importance of localization:
Code

(page 17)
...For instance, the code

for i = 1, 1000000 do
  local x = math.sin(i)
end

runs 30% slower than this one:

local sin = math.sin
for i = 1, 1000000 do
  local x = sin(i)
end


And this one was new to me (initialization of table entries):
Code

(page 20)
.. the next loop runs in 2.0 seconds:

for i = 1, 1000000 do
  local a = {}
  a[1] = 1; a[2] = 2; a[3] = 3
end

If we create the tables with the right size, we reduce the run time to 0.7 seconds:

for i = 1, 1000000 do
  local a = {true, true, true}
  a[1] = 1; a[2] = 2; a[3] = 3
end
Njyldgarkn init/prepare process x no. of render blocks x no. of passes
Posted: May 18, 2012 2:55 am   Details E-Mail

Join Our Community!

Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!

33,712 Registered Users
+19 new in 30 days!

153,534 Posts
+32 new in 30 days!

15,348 Topics
+73 new in year!

Create an Account

Online Users Last minute:

19 unregistered users.

Recent Forum Posts:

Join our Forum Join our Forum
Over 30 000 members!
Join us on Facebook Join us on Facebook
Over 42 000 likes!
Follow us on Twitter Follow us on Twitter
Get updates quickly!
Follow us on Instagram Follow us on Instagram
Tag us #filterforge