Just a silly flow question I think...?

[Scrripty]

I have a question with code example.  How much of a difference does a few extra lines of code really make?  Like in this example:

Code: [Select]

       menu get specials  ;primary
        IF #menures = 2 && #mana >= !PrimaryMana
        {
          gosub execPrimary
          RETURN
        }
        menu get specials  ;secondary
        IF #menures = 3
        {
          IF #mana >= !SecondaryMana
          {
             gosub execSecondary
          }
          RETURN
        }
      RETURN
The top part of the sub is done with the if built into the first if... basically just combined, and the bottom one is the "old" way I did it.  Would it really make all that much difference in a few thousand lines of code if I went through and changed them to the "new" way?  I have a LOT of subs that look like this tho, and I could probly condense a LOT like this...  Worth it or no?  And why if you would...  It cuts that first part of the sub down to 6 lines from 10.  If the script is processing 10 lines of code per cycle... that's a pretty big net in speed isn't it?  Like 40 percent over the course of a large script, and if you don't have any #lpc optimizing done like me...

[Masscre]

It solely depends on the amount of time and processes that the live compiler has to do to get it done.  It could make the process easier and in case make the run less cpu dependant, which inpoint would make the script run faster or could load something up or make it take more steps to finish the process incase offsetting the timing and also making the whole process as a whole alot slower.

[Scrripty]

It solely depends on the amount of time and processes that the live compiler has to do to get it done.  It could make the process easier and in case make the run less cpu dependant, which inpoint would make the script run faster or could load something up or make it take more steps to finish the process incase offsetting the timing and also making the whole process as a whole alot slower.

Well I'm to the point now where I can FEEL I need some speed.  If that makes sense.  I know I can optimize a TON of script and take out a LOT of lines.  I bet I could cut out about 20 percent of my script by just optimizing with what I've learned.  I'm just wondering how much I'll ACTUALLY gain.  I have #lpc set to 10 in the script.  That's VERY low.  I could set it to 14 and get the same benefit right?

[Masscre]

Yes and no depends on the processing being done that you are speeding up. Also how it will handle on a dial-up, DSL, Cable connection. Also if it is just processing lines or if its is waiting for actions. This will make a big difference.  But the best way to know is to try it out. 

[Scrripty]

I'm just trying to prioritize what I ACTUALLY want to do in my head.  I think I'll just optimize.  With my new menu, I can almost visually see each thing processing now when I set how often the menu updates to really low.  It's given me some really good insight into how things are getting processed.  Plus it's gotten so big, and there's so much being done, I really have to prioritize WHAT gets done first, and do it based on how important it is that each specific thing is done at what time.  It's annoying.  So I'm considering ways to eek out every bit of script and time I can.  Optimizing casting is one way.  By FORCING the sub to wait for faster cast recovery to be up and not returning out and coming back... I'm saving some time and cycles there.  Not making the script endlessly loop through stuff it's just going to sub out of anyways to come back and cast the same thing...  when all it would take is a .50 second wait for the fcr to be up and cast the spell...  I guess that's more flow optimizing.  But if I take out 20 percent of the script, that's 20 percent more it's going to check subs that might need to cast in theory right?   Sorry just thinking out loud.

[Cerveza]

If you really want to see where your speed is going just put a timer in. Use a simple display to show the current #sCnt, then have it displayed at various points in your script.

I like it in a menu, but you could put it over your head....

Code: [Select]

loop
if something A
  gosub A
if something B
  gosub B
until #false

sub A
event ExMsg #charID 3 0 Sub A begin #sCnt
the rest of Sub A
event ExMsg #charID 3 0 Sub A end #sCnt
return
Granted that adds some cycles to the entire process, but it allows you to see exactly how much time is being spent in each part of the script.

[Scrripty]

I'll have to send the newest version to you in your junk mail Cerv.  I've got checks upon checks now.  It tells you where it's at, what it's doing, low mana checks for everything... I've been using that to diagnose problems.  Also my new menu allows you to "see" it visually if you let it update in near real time.  It's fun to watch.  When I get all the info I want on the new menu, diagnosing suit problems will be so easy.

[Cerveza]

Cool, I'll look forward to using it one day, if EUO ever updates LOL.

I like having a "diag" mode in scripts. Turn it on/off at the beginning and allow you to see timings, or other things going on.

[Scrripty]

Cool, I'll look forward to using it one day, if EUO ever updates LOL.

I like having a "diag" mode in scripts. Turn it on/off at the beginning and allow you to see timings, or other things going on.

That's a good idea, I'm not so far along with it, that I can't add a menu option and make it a diagnostic mode.   if #menures = #true's all over the place with little bits of info on what's going on at that exact moment?  I like it.  I'll add that to the "SHOULD HAVE BEEN DONE YESTERDAY" list.

[Masscre]

This all sounds good Twinkle McNugget and i like you thought process.  I want to look over some of your diag process to get some ideas for mine

[Scrripty]

This all sounds good Twinkle McNugget and i like you thought process.  I want to look over some of your diag process to get some ideas for mine

If you haven't seen the new menu there's a picture of it here. http://www.scriptuo.com/index.php?topic=2166.msg19670#msg19670

There's also an old version in that thread somewhere attached to a post.  It's got all the old casting errors tho that I've since fixed.  Well I'm actually still working on them, but they've pretty much got a fork stuck in them cause they're DONE.

[Endless Night]

setinng LPC 100   would effectively be a 10x increase in speed.  Dont be affraid to set the LPC higher in certain sections of your code .. just as fast journal scanning.. set LPC 1000 and then set back down after journal scan is done.

In my buffbar scanner (pixel scanning) the LPC is defaulty set to 9999  (bascially max)

As far as you code... Less lines is easier to read thus debug and the newer method needs less {} so thats better... But might I also suggest that you start thinknig about only useing one Return Per sub.. makes code much more resilient in the long run.  Eg like below

Code: [Select]

menu get specials  ;primary Or Secondary
set !MenuRes #MenuRes
IF !menures = 2 && #mana >= !PrimaryMana
   gosub execPrimary
IF !menures = 3 && #mana >= !SecondaryMana
   gosub execSecondary
RETURN
Note: Less that 1/2 the lines used as your original code and i find much easier to read.

[Scrripty]

Yea I know about #lpc, but why does one return make code more resilient?  Oh I think I get it... it's just less lines... and less jumping around... more compact and such?  I have SO much jumping around tho... I should throw my ls sub up so you can see THAT monster. haha  I did it.   I can cut a TON out of that... 

Code: [Select]

 ;==========================Lightning Strike==================================
  sub ls
    menu get 13 ;Lightning Strike;Primary:Secondary
    IF #menures = #true
    {
      menu get 14          ; WS Mana Check
      IF #menures = #true
      {
        menu get specials  ;ls
        IF #menures = 1 && #mana > !LSManaPercentage
        {
          gosub lsSpecial
          RETURN
        }
        menu get specials  ;primary
        IF #menures = 2 && #mana >= !PrimaryMana
        {
          gosub execPrimary
          RETURN
        }
        menu get specials  ;secondary
        IF #menures = 3
        {
          IF #mana >= !SecondaryMana
          {
             gosub execSecondary
          }
          RETURN
        }
      RETURN
      }
      menu get 25          ;Curse Wep
      IF #menures = #true && !CRWTimer < #sysTime
         gosub CurseWeapon
      menu get specials    ;ls
      IF #menures = 1
      {
         gosub lsSpecial
         RETURN
      }
      menu get specials    ;primary
      IF #menures = 2
      {
        IF #mana >= !PrimaryMana
        {
           gosub execPrimary
        }
        RETURN  
      }
      menu get specials     ;secondary
      IF #menures = 3
      {
        IF #mana >= !SecondaryMana
        {
           gosub execSecondary  
        }
        RETURN
      }  
    }
  RETURN
  ;============================================================================

[TrailMyx]

I have to agree with EN with the lots-o-returns.  This section:

Code: [Select]

        menu get specials  ;ls
        IF #menures = 1 && #mana > !LSManaPercentage
        {
          gosub lsSpecial
          RETURN
        }
        menu get specials  ;primary
        IF #menures = 2 && #mana >= !PrimaryMana
        {
          gosub execPrimary
          RETURN
        }
        menu get specials  ;secondary
        IF #menures = 3
        {
          IF #mana >= !SecondaryMana
          {
             gosub execSecondary
          }
          RETURN
        }
      RETURN

Can be trimmed to:

Code: [Select]

        menu get specials  ;ls
        IF #menures = 1 && #mana > !LSManaPercentage
          gosub lsSpecial

        menu get specials  ;primary
        IF #menures = 2 && #mana >= !PrimaryMana
          gosub execPrimary

        menu get specials  ;secondary
        IF #menures = 3 && #mana >= !SecondaryMana
             gosub execSecondary
      RETURN

That seems just more readable to me and doesn't change execution flow too much.

[Scrripty]

I have to agree with EN with the lots-o-returns.  This section:
That seems just more readable to me and doesn't change execution flow too much.

While you were posting that I did this:
Basically cut that sub in half.  Sped it up by double then... Should net me a tiny bit of speed when toggling specials...  Thanks guys, I'm gonna keep looking.  Remember this is my FIRST full fledged script I've EVER done.  I've done TONS of little things, a few hundred lines... but this is huge to me.   I'm at 3000 lines and counting now.  Lots of documentation tho.  That's what I was saying I could probly cut the script by AT LEAST 20 percent, and if that sub is any indication I could probly go 40 to 50.

Code: [Select]

 ;==========================Lightning Strike==================================
  sub ls
    menu get 13 ;Lightning Strike;Primary:Secondary
    IF #menures = #true
    {
      menu get 14          ; WS Mana Check
      IF #menures = #true
      {
        menu get specials  ;ls
        IF #menures = 1 && #mana > !LSManaPercentage
          gosub lsSpecial
        menu get specials  ;primary
        IF #menures = 2 && #mana >= !PrimaryMana
          gosub execPrimary
        menu get specials  ;secondary
        IF #menures = 3 && #mana >= !SecondaryMana
           gosub execSecondary
        RETURN
      }
      menu get specials    ;ls
      IF #menures = 1
         gosub lsSpecial
      menu get specials    ;primary
      IF #menures = 2 && #mana >= !PrimaryMana
         gosub execPrimary
      menu get specials     ;secondary
      IF #menures = 3 && #mana >= !SecondaryMana
         gosub execSecondary
    }
  RETURN
  ;============================================================================