16 Replies Latest reply on Feb 8, 2007 1:13 PM by MikerRoo

    convert to cfscript to increaase performance

    EmmanuelRuiz Level 1
      Can the attached code be easily converted to cfscript? Need a boost in performance.

      Txs
        • 1. Re: convert to cfscript to increaase performance
          Level 7
          Can the attached code be easily converted to cfscript? Need a boost in
          performance.

          Txs

          <cfset tBean.setCOSTCENTERNUMBER(line.substring(0,4))/>
          <cfset tBean.settripNumber(integer.parseInt(line.substring(12, 19)))/>
          <cfset tBean.setDEPARTUREDATETIME(createDatetime(line.substring(19,
          23),
          line.substring(23, 25), line.substring(25, 27), line.substring(27, 29),
          line.substring(29, 31), 0))/>


          Yes it can, but I doubt it will give you much of a performance boost.
          That rule of thumb is not very relevant with the advent of the MX era of
          CF Server.

          But I suspect it would be much easier to read, for me at least.

          <cfscript>
          t.Bean.setCostCenterNumber(line.substring(0.4));
          t.Bean.setTripNumber(integer.parseInt(lin.substring(12,19));
          tBean.setDepartureDateTime(createDateTime(line.substring(19,23),
          line.substring(23,25), line.substring(25,27), line.substring(27,29),
          line.substring(29,31),0));
          ...
          </cfscript>

          I would hazard a guess that all that string processing is at least one
          of your performance bottlenecks.

          • 2. Re: convert to cfscript to increaase performance
            MikerRoo Level 1
            String processing slows a little, iif() slows a great deal.
            Eliminate that for the biggest boost.
            • 3. Re: convert to cfscript to increaase performance
              Level 7
              > Can the attached code be easily converted to cfscript? Need a boost in
              > performance.

              It seems to be a bunch of <cfset> statements, so yes it can. And whilst
              changing it to CFScript will earn you a small (VERY SMALL) performance
              gain, it's not going to be statistically significant compared performance
              gains/hits your're experience just from CF and Java and the OS doing their
              thing in the background, or how many users you have on your site at the
              time or that sort of background noise. So definitely a theoretical gain
              rather than a practical one.

              It does make the code look a lot more tidy, though.

              I'd be going over the code in your methods to see if there can be any
              improvements. As they're all setters, I imagine there's not a great deal
              to them, but I'd be timing each to see if there's anything unexpected going
              on.

              One thing I note is that you have DE() calls around numbers. Not
              necessary.

              I also think all the string ops will slow you down, but it's perhaps not
              something you have much choice over.

              If tBean is a CFC instance rather than a Java object, I'd drop all the
              parseInt() stuff, as it's not necessary. If it IS a Java object, try
              javaCast() instead of parseInt() (not sure which would be faster, but might
              be worth looking at). If it's a CFC instance, use name/value pairs for
              your arguments. If will yield a SLIGHT performance improvement (as well as
              improving the readability of your code slightly).

              Is using subString() faster than mid()?

              If your setters are really simple, such as:
              <cfset variables.foo = arguments.foo>
              (or the Java equivalent, if it's Java).

              Then consider using a setMemento() method that sets the whole lot in one
              fell swoop, instead of being so granular. If it so transpires down the
              track that you need specific setters, then change the calling code @ that
              time (or change the setMemento() to call the specific setter for those
              properties than need specific setters.

              How long - when the server is busy - is this code taking to run?

              --
              Adam
              • 4. Re: convert to cfscript to increaase performance
                Level 7
                > iif() slows a great deal.

                Are people STILL peddling that myth?

                It doesn't, you know. Try it.

                --
                Adam
                • 5. Re: convert to cfscript to increaase performance
                  MikerRoo Level 1
                  quote:

                  Originally posted by: Newsgroup User
                  > iif() slows a great deal.

                  Are people STILL peddling that myth?

                  It doesn't, you know. Try it.
                  -Adam



                  Only people who know what they are talking about.

                  (1) I have tried it, repeatedly, for fools who don't heed wisdom and are too lazy to test it themselves.
                  For the simplest scenario, the IIF-less code is over three times faster than with IIF.
                  The more involved the code, the bigger the savings.
                  • 6. Re: convert to cfscript to increaase performance
                    MikerRoo Level 1
                    BTW, over in over in the docs, the people who know what they are talking about still tell you that IIF() and evaluate() carry big performance hits.

                    See http://livedocs.macromedia.com/wtg/public/coding_standards/performance.html for just one of many instances.
                    • 7. Re: convert to cfscript to increaase performance
                      Dan Bracuk Level 5
                      quote:

                      Originally posted by: MikerRoo
                      Only people who know what they are talking about.
                      (1) I have tried it, repeatedly, for fools who don't heed wisdom and are too lazy to test it themselves.
                      For the simplest scenario, the IIF-less code is over three times faster than with IIF.
                      The more involved the code, the bigger the savings.


                      For my own curiousity, when you tried it (iif), what did you compare it to?
                      • 8. Re: convert to cfscript to increaase performance
                        Level 7
                        > BTW, over in over in the docs, the people who know what they are talking about

                        In my experience, that's debatable, but that's irrelevant to this.


                        > See
                        > http://livedocs.macromedia.com/wtg/public/coding_standards/performance.html for
                        > just one of many instances.

                        Yep. that's the very assertion that lead me to investigate the situation.

                        Bottom line is: on CF5, that was correct. On CFMX, not so much (and
                        certainly not enough to worry about). On CFMX7, even less still.

                        The reason seems to be - as near as I can tell - is that iif() uses the
                        same code as evaluate() does, when it needs to do a runtime evaluation on
                        the second or third argument of the iif() statement. And we all know how
                        slow evaluate() used to be. With the performance improvements that CFMX
                        and CFMX7 brought to evaluate(), similarly the issue with iif() has all but
                        vanished.

                        In situations where there is no runtime evaluation needed:
                        - when the arguments are tokens such as numbers or TRUE / FALSE),
                        - the values have de() around them;
                        iif() is faster than the equivalent <cfif><cfelse></cfif>. But not, I
                        hasten to add, by a factor significant enough to worry about.

                        When it needs to evaluate() runtime arguments, it is indeed slightly
                        slower, some of the time. But we're talking about units of ten ms over
                        10000 iterations (on my poxy laptop), and the margin of error each time was
                        more than the difference was each time. I'd say that's insignificant.
                        Wouldn't you?

                        Bottom line, the problem was always down to the "evaluate" part of the
                        situation, not iif(), intrinsically. And the problem dun't exist any more.

                        --
                        Adam
                        • 9. Re: convert to cfscript to increaase performance
                          MikerRoo Level 1
                          quote:

                          Originally posted by: Dan Bracuk
                          For my own curiousity, when you tried it (iif), what did you compare it to?



                          It's obvious isn't it? You compare an IIF version of code with the exact equivalent non-iif code.
                          Something that Adam has obviously never done.

                          To greater isolate the effects of iif you put it in a loop.

                          See the attached code or post your own.
                          Note that the test file as a whole is penalized for the iif. If you create two separate files, the performance differences, overall, are even larger.


                          • 10. Re: convert to cfscript to increaase performance
                            Level 7
                            > It's obvious isn't it? You compare an IIF version of code with the exact
                            > equivalent non-iif code.
                            > Something that Adam has obviously never done.

                            You know how I reminded you the other week that you have become quite
                            bolshy recently? Same applies here. Why don't you re-read your posts and
                            try to objectively consider your tone. I suggest you pull your head in
                            (all the more for reasons explained below).


                            > To greater isolate the effects of iif you put it in a loop.

                            Yes. I ran your code on my laptop (2GHz Pentium-M , 1GB RAM: not very
                            quick really: certainly nothing like the performance of a production
                            server), on CFMX 7.0.2.

                            And over your 4000 iterations (the final loop) test, after repeated re-runs
                            I see that the results go *either way*, and the sum total runtime for the
                            test is either 0ms or 16ms.

                            About eight tests out of ten, the results favour if() over iif(). But
                            there's still nothing in it. And I would call that "within margin of
                            error".

                            At worst, that would be a difference of 0.004ms per iteration. Not
                            *seconds* (which still would be insignificant), but MILLIseconds.

                            So I've run your own code... and it demonstrates you're mistaken: there is
                            simply no significant difference between iif() and if().

                            Which bears out:
                            a) my own testing;
                            b) what I said.

                            So... WTF are you on about?

                            Why didn't you just say "oh hey, sorry: didn't realise things had changed,
                            I'll remember that", instead of going to great lengths to demonstrate to
                            everyone you're... well... *wrong*?

                            That said, obviously you're not a complete idiot, and have run this code
                            yourself: what were your own findings? Not a "oh hohoho, how silly Adam
                            is, I'm right, I'm right, I'm right", but... *the actual figures*? I'm
                            keen to understand why it is you think there's this big difference. What
                            were your test results?

                            Oh, hey... I also recommend not relying on <cftrace> to output performance
                            telemetry, as it relies on debugging being switched on. The CF debugging
                            service adds an awful lot of overhead to processing, and increases the
                            margin of error even more (almost all the processing time is debugging
                            overhead, which negates the accuracy of test rigs like this). I'm seeing
                            some of the test results (either way) blow out by a factor of five when
                            debugging's on. The results are far more uniform with it off.

                            I find most of your postings here (up until a few recently) to be quite
                            thoughtful and helpful... much more than those of some people around here
                            (I imagine you know to whom I am referring here). But you seem to have
                            gone off the rails a bit recently. Sad.

                            --
                            Adam
                            • 11. Re: convert to cfscript to increaase performance
                              Level 7
                              Mike's little conniption aside, Emmanuel: how did you go with optimising
                              your code?

                              --
                              Adam
                              • 13. Re: convert to cfscript to increaase performance
                                MikerRoo Level 1
                                Edit note for news groups...

                                Transcribed the second table wrong from the logs.
                                The correct table is attached....

                                • 14. Re: convert to cfscript to increaase performance
                                  Level 7
                                  > Mean 103.15 33.5
                                  > Std Dev 51.05 30.38

                                  What version of CF is this on? And what sort of PC?

                                  You're certainly seeing more of a difference than I am (running same code).
                                  Which is interesting.

                                  I think your mean and SD figures are less meaningful than they could be,
                                  because each trial has a different number of iterations. So rather than
                                  basing your stats on the twenty figures presented, it'd make more sense -
                                  possibly - to bear in mind the number of iterations as well, weighting the
                                  results accordingly. But that's by the by: the difference is clear in the
                                  actual figures.

                                  That said... even taking the widest margin: 260ms cf 30ms (over 2800
                                  iterations, round 14 of the tests)... that's a difference of 0.08ms per
                                  iteration. So: trivial.

                                  Taking perhaps the kindest results to your POV, test 3: the difference is a
                                  wopping 0.25 MILLIseconds, per iteration.

                                  Other than to defend your position (which needs as much defence as it can
                                  get, granted), would you really consider that a significant problem? Is
                                  that where you'd focus your performance tuning? Really?

                                  I've D/L CF5, and will install it somewhere. It'll be interesting to see
                                  the results on that (which WILL show a significant performance hit on
                                  iif()), which is where the whole notion of "iif() is slow" is based.

                                  --
                                  Adam
                                  • 15. Re: convert to cfscript to increaase performance
                                    EmmanuelRuiz Level 1
                                    I've actually setup cfscript for code readability. This code I inherited from a previous programmer, now that the page to be parsed is getting a lot bigger, performance issues popped up.

                                    Thanks for the feedback. Didn't expect so much but I sure enjoy the debate.
                                    • 16. Re: convert to cfscript to increaase performance
                                      MikerRoo Level 1
                                      Wow Adam,

                                      It is fascinating to watch you twist and squirm, denying reality, to try and justify your blatantly wrong position.

                                      One approach is three times worse? Well not if you only count only one hand-picked iteration!

                                      So, your argument is that no cf developer should ever process more than one row of data at a time?

                                      BTW, that is just the TRACE time. If you look at first-request processing time, Iif () will add 2 or more seconds on similar atomic test rigs because of the problems of precompile.

                                      So, every time you edit a page or every time CF decides to refresh its cache, your site performance tanks.

                                      To answer your question, the two tables above came from CF 7.02, Win XP pro.
                                      CF 7.01, CF7, CF 6.1, CF6, and CF5 on Linux, Win 2k server and Win 2003 server all give similar results.

                                      But, since you are being so dishonest, I see no point trying, any further, to correct a closed mind.

                                      People can run my posted test rig (or make one for themselves) and see the truth easily enough.