convert to cfscript to increaase performance

[EmmanuelRuiz]

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

Txs

[Newsgroup_User]

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.

[MikerRoo]

String processing slows a little, iif() slows a great deal.
Eliminate that for the biggest boost.

[Newsgroup_User]

> iif() slows a great deal.

Are people STILL peddling that myth?

It doesn't, you know. Try it.

--
Adam

[MikerRoo]

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.

[MikerRoo]

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.

[Dan_Bracuk]

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?

[MikerRoo]

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.

[Newsgroup_User]

> 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

[MikerRoo]

See the attached...

[MikerRoo]

Edit note for news groups...

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

[Newsgroup_User]

> 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

[MikerRoo]

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.

[Newsgroup_User]

> 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

[Newsgroup_User]

> 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

[Newsgroup_User]

Mike's little conniption aside, Emmanuel: how did you go with optimising
your code?

--
Adam

[EmmanuelRuiz]

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.