Let's talk about efficiency for a while

[Ruke]

how're you my friend c:.

come on in, take a sit. let's talk a little bit about effiency.

you know, too much efficiency can turn us in crazy-people.
as you know, everything in high quantity is bad.

efficiency guy

someone say efficiency?!

people think too much in efficiency these days, instead of
worry about the task of their code, they're more concern
about its effiency, even when they clearly dont need it.

people sometimes dont want to use bjs, because they are slower.
yes, they're "slower", but they (most of them) help us to not repeat our self.
they're a gift from blizzard, accept it , dont be rude, gifts always are accepted.
but seriusly, they say slower like if it will were to restart your machine because of that .

chuck norris accepts bjs

as i was saying, dont spend your hole time making
your code super-efficiency, it is not worthy.
instead, use it to make new, great stuffs !.
if you can see (you really can) that your code is slow,
then you're able to work on efficiency, only then .

that sound logical, right?

of course it does.

but, what happens if i really like to make my code really really, REALLY efficient?
well you can do it of course, but don't bother other people with it please.

but, aren't you bothering efficiency people?

am i?, is good to know

-----------------------------------------------------------------------

hope you liked this opinion with a little bit of humor.
dont take it personal, and insults sorted from a to z please.

 

[muzzel]

Whilst deep down in my heart i share your opinion that simplicity and readability are often more valuable than naked performance (most BJs however are not elegant) i still think you should really work on how you present your ideas. Those gifs look retarded.

Please delete your thread or at least the pictures. Otherwise il have to flame the moderators until they do so... (hello meg!)

Insults:
Asshole
Bullshit
Crap
Dumbfuck
E... someone else may take it from here

 

[Ruke]

Whilst deep down in my heart i share your opinion that simplicity and readability are often more valuable than naked performance (most BJs however are not elegant) i still think you should really work on how you present your ideas. Those gifs look retarded.

Please delete your thread or at least the pictures. Otherwise il have to flame the moderators until they do so... (hello meg!)

Insults:
Asshole
Bullshit
Crap
Dumbfuck
E... someone else may take it from here

i did try to use spoiler tags, but they dont work :\.
but cmon, they're fun xD.

 

[Adiktuz]

if you want to hide something with a button

[hidden=""][/hidden]

if you want to simply hide a text

Spoiler

[spoiler][/spoiler]

 

[PurgeandFire]

Good post about effiency. +repz I approve of the gifs

 

[chobibo]

If this is about BJ functions and people saying not to use them, then it's not a speed freak's suggestion (at least some), some of the BJ functions leak handles, and some aren't straightforward enough.

If this was brought about my suggestion ConditionalTriggerExecute, then sorry, but I think the code:

    if TriggerEvaluate(trig) then
        call TriggerExecute(trig)
    endif

the code in the function is too simple to be separated by its own function, I mean that wouldn't make the main code cluttered. You got me confused with the real efficiency people. They then tend to suggest to use TriggerConditions instead of TriggerActions because the latter is faster.

 

[SA Dashie]

Although there are times when efficiency is vastly important.
Mostly in code that is recycled alot though.

There's no point in bickering about efficiency in the use of a basic initialize GUI code block that only executes one basic function though. lol

 

[Daffa]

For me, efficiency only comes when coding spells or long systems which can cause lags if wrong measures are taken.

 

[Tal'Rarity]

We need a GUI-only Spell Mod.

However I rather efficiency over difficulty just because I have advanced far enough to do it quickly as well the stuff I make requires speed.

 

[Nestharus]

How I view it is that some things need efficiency and some things don't.

If you are writing a system to handle around 8000 units and expect events or w/e to be firing 100 times a second, then you might want to make that efficient and robust. If you are doing a single spell and you don't expect it to fire that often, maybe at most 3 at once (if three of the same hero), then you don't need to concern yourself so much about efficiency.

Large Scale = efficiency
Small Scale = not so much

A small piece that can be used in a big thing should also be as efficient as possible, because if the person needs efficiency, they are not going to urs ur thing if it isn't super efficient ; P.

It just all depends.

A really great example is BigInt. I had to optimize that several times to make it not freeze the game for a moment. The optimizations are so severe that it's only accurate up to 240 digits for division, after that it loses accuracy.

 

[muzzel]

Technically i agree with you Nestharus.

But ive never seen a map project fail because of bad trigger performance. Projects usually fail because of the excessive amount of time the mapping takes up.

Also i dont agree with your terminology, imo "performance" is the speed or amount of caused lag of your code/trigger in runtime while the "efficiency" of a code is how much coding is required to achieve a certain task.
So efficient code is something very important (commonly underestimated) for making triggering easier, faster and more maintainable. Performance is something that is actually really nice but usually comes at the cost of efficiency.

I think everyone has his own idea about the perfect ratio of efficiency and performance, mine is very pro-efficiency.
Law of nature: both extremes dont work out.

More insults:
Eejit
Fucktard
Goose

 

[Nestharus]

Well, extreme performance does work out for things like BigInt, BooleanExpression, and Network ^)^.

 

[-Kobas-]

Even small things can become problem, if you have, you know, a lot of small things.

 

[axleion]

Even small things can become problem, if you have, you know, a lot of small things.

agreed.

Also i dont agree with your terminology, imo "performance" is the speed or amount of caused lag of your code/trigger in runtime while the "efficiency" of a code is how much coding is required to achieve a certain task.
So efficient code is something very important (commonly underestimated) for making triggering easier, faster and more maintainable. Performance is something that is actually really nice but usually comes at the cost of efficiency.

I think everyone has his own idea about the perfect ratio of efficiency and performance, mine is very pro-efficiency.
Law of nature: both extremes dont work out.

nope, inefficient codes won't result in high performance, and high performance never comes from inefficient codes. so actually that efficient and performance of yours go hand in hand, you can't go for one while leave the other one.

 

[SA Dashie]

^There is such code versions that can be made for systems.
- This being that the periodic functions are checked more often, although result in less lag each time run.
- While the other resulting in less periodic checks, although result in a little more lag every time run.

I would usually like going with the first option more often, although sometimes are made different ways that don't just effect efficiency.


I am guessing that performance with these two different options can reflect off of how the rest of the maps code is built.

 

[muzzel]

nope, inefficient codes won't result in high performance, and high performance never comes from inefficient codes. so actually that efficient and performance of yours go hand in hand, you can't go for one while leave the other one.

i couldnt disagree more

 

[Frotty]

i couldnt disagree more

I couldn't agree more with disagreeing

 

[Xonok]

Writing good(efficient) code in any language takes lots of thinking. In this sense it is not high performance, because the actual development is slow.

 

[muzzel]

Writing good(efficient) code in any language takes lots of thinking. In this sense it is not high performance, because the actual development is slow.

ur mixing up those words:
efficiency: fast development
performance: runtime

 

[Xonok]

ur mixing up those words:
efficiency: fast development
performance: runtime

Could be taken either way. I guess it doesn't matter much, as the point isn't different.

 

[chobibo]

muzzel is talking about code efficiency, it's not the same as run-time performance.

 

[Adiktuz]

taking from chobibo's link:

Code efficiency is a broad term used to depict the reliability, speed and programming methodology used in developing codes for an application. Code efficiency is directly linked with algorithmic efficiency and the speed of runtime execution for software. It is the key element in ensuring high performance. The goal of code efficiency is to reduce resource consumption and completion time as much as possible with minimum risk to the business or operating environment. The software product quality can be accessed and evaluated with the help of the efficiency of the code used.

So code efficiency is needed for high performance...

 

[Ruke]

@nes: that is exactly what i'm talking about. you're trying to optimize triggers. i don't know why but, triggers?, really? : \

@Frotty: i take my imaginary hat off, you and the contributors did and excellent job at wurst (why that name by the way?, and plz, define, people want define D, my congratulations.

 

[Nestharus]

@nes: that is exactly what i'm talking about. you're trying to optimize triggers. i don't know why but, triggers?, really? : \

the goal wasn't to optimize triggers, but to provide a good way of doing TriggerRemoveCondition. The trigger performance boost was just a bi-product. The current performance issues having to do with BooleanExpression don't have to do with the triggers themselves, but with the way the memory is being stored. If the memory is stored incorrectly, then there will be major performance issues, not with the trigger evaluation, but with the trigger rebuilding. When a trigger is rebuilt in a naive manner, it's O(n) per rebuild, and with references and so forth, this can mean that the op limit will be reached within 3 operations, and yes, I am not exaggerating. Even now, with all of the performance increases, it can still only handle perhaps 3 heavy operations and 10 light operations. Also, we go back to the original problem of memory. There is not enough memory in an array to handle BooleanExpression, so the memory has to be expanded through the use of hashtables, which can only do 66% of the operations that an array can do. You may say, big deal, but 66% of an already very limited amount of operations is a big deal, lol.


Performance is important in some cases, and BooleanExpression is one such case.


Another prime case of course is BigInt. Before I performed optimizations on it 3 different times, I was receiving complaints from people that it wasn't fast enough. Yes, and keep in mind that the first time I wrote it, I already wrote it to be fast.


BooleanExpression and Trigger were made for unit specific events, and don't you dare say "why not just use triggers then?" without thinking about it first and considering priorities across global and unit specific events

If you say remove on a timer, then you've broken the behavior of TriggerRemoveCondition

If you say to just use trigger actions, now we're running into performance problems that will reduce the player's FPS in heavy maps

 

[chobibo]

So code efficiency is needed for high performance...

Precisely, that's why I gave the link to Xonok. His definition of high performance was:

Writing good(efficient) code in any language takes lots of thinking. In this sense it is not high performance, because the actual development is slow.

My point was that good code is a balance between the two. Also efficiency and performance cannot be interchanged since they have unique or different definitions.

Could be taken either way. I guess it doesn't matter much, as the point isn't different.

 

[Ruke]

@nes: that looks better, i thought that it was only because of the little performance gain.

 

[Dr Super Good]

I cannot believe that the main post was actually serious after all those images...

Anyway efficiency is not as important as many people make out. Although higher efficiency is always better than lower efficiency the value of efficiency varies entirely based on the usage of the piece of script.

For the case of a once firing trigger used as part of map progression (such as main quest progression) efficiency is worth virtually nothing. The code only fires once and might require a high level of complexity due to its nature. Wasting time to optimize this sort of script will drive you mad as progress will become painfully slow.

For the case of a repeatedly running routine (such as a knockback system) efficiency is worth everything. The code fires dozens of times every second and often has a low complexity due to the simplistic nature of the task. Spending time to optimize this sort of script is highly rewarding as it will noticeably improve map performance.

 

[muzzel]

I cannot believe that the main post was actually serious after all those images...

im sorry, we were not aware that you have a sense of humour o.o

Anyway efficiency is not as important as many people make out. Although higher efficiency is always better than lower efficiency the value of efficiency varies entirely based on the usage of the piece of script.

For the case of a once firing trigger used as part of map progression (such as main quest progression) efficiency is worth virtually nothing. The code only fires once and might require a high level of complexity due to its nature. Wasting time to optimize this sort of script will drive you mad as progress will become painfully slow.

For the case of a repeatedly running routine (such as a knockback system) efficiency is worth everything. The code fires dozens of times every second and often has a low complexity due to the simplistic nature of the task. Spending time to optimize this sort of script is highly rewarding as it will noticeably improve map performance.

after all these discussions about the correct terminology i assume you are talking about performance, not efficiency... ?

 

[JAMES SOUTHERLAND]

The United States government is the model of efficiency. NOT REALLY LOL

 

[Dr Super Good]

after all these discussions about the correct terminology i assume you are talking about performance, not efficiency... ?

As far as I am aware, both are interchangeable in computer science.

Performance generally is used with measurable characteristics. For example frame rate can be used as a performance indicator and so code that produces higher frame rate can be considered to perform better than code that produces a lower frame rate.

Efficiency is much more broad. It could cover anything from the activity of programming itself to the code that is being created. For example you could say that using a loop to repeat a function call thousands of times is more efficient than calling the function 1000 times in a row.

 

[muzzel]

Okay, you didnt read the thread. Nevermind then.