Latest Beta

[ProgAndy]

You should feel worse. That means it's linked against a version of ATL that may be insecure.

Or it doesn't use ATL at all?

[Valik]

Or it doesn't use ATL at all?

I think you missed the point. The slowdown is mostly caused by the following two things:

• Programs were doing something insecure in not validating their parameters. Now some programs are validating their parameters and actively rejecting invalid parameters. This extra validation, of course, takes time.slows things down.
• Since programs are now validating their parameters more stringently AutoIt has to be sure it passes the correct thing. If it passes the wrong thing (which worked in the past) then the method will fail. The extra work AutoIt has to do slows things down.

Programs that don't use newer versions of ATL aren't as likely to be validating parameters so they will work less slow. That also means those programs may be insecure since they aren't using newer, better versions of ATL.

So the best case scenario is you are using slower objects that work more secure than in the past... and work at all as a result of trancexx's changes to Autoit.

[Zedna]

@Valik

What version of Autoit is the last fast one?

[Valik]

I don't care?

[Zedna]

It's good to know for case of time critical applications. I can compile such applications with such "last fast" version of Autoit.

I know developers don't like that idea but I have no problem with using older versions when it's better and positives are bigger than negatives.

EDIT: I still use old 3.2.12.1 version for many my older projects because I don't want to migrate/test so many scripts to totally new syntax.

Edited October 27, 2011 by Zedna

[KaFu]

The first time I've read of it was in this post:

Anybody notice a HUGE performance difference with COM in the Beta version (versus Production)? The below code runs an average of 5x slower on 3.3.7.18 than on 3.3.6.1! (tested in both 32 and 64-bit mode).:

So maybe give 3.3.7.17 a try?

[Valik]

I guess you guys are too concerned about speed to realize the older version that runs fast is broken. As in things do not work. But whatever, do what you wish.

[Zedna]

I guess you guys are too concerned about speed to realize the older version that runs fast is broken. As in things do not work.

You said that it's slow just because of testing for good/bad parameters.

So if I'm sure I pass good parametersin my program (logically correct script/data) then it works fine also with older fast Autoit.

So it can't be called "broken". It can be broken only with badly written scripts.

[Valik]

You said that it's slow just because of testing for good/bad parameters.

So if I'm sure I pass good parametersin my program (logically correct script/data) then it works fine also with older fast Autoit.

So it can't be called "broken". It can be broken only with badly written scripts.

You are completely wrong.

[KaFu]

...

[Ascend4nt]

I'd like to ask why the use of ATL was brought into this discussion? ATL is a programming library that COM object programmers (the providers of the interfaces) can use to program COM interface objects, and is not an option that an outside application (like VB script, AutoIt) has any control over. Basically, it looks like that term is being used to blindside people in answering questions as to why the COM interface is slower. Nothing but the way AutoIt is using the same objects is being changed here. Its not magically choosing an object that was programmed one way over another.

*edit: used wrong acronym (doh)

Edited November 3, 2011 by Ascend4nt

[trancexx]

All is said already. Anyone who wants can read what's said. But do read with understanding and you will see that all questions are answered.

Next person talking about this is gay. And dumb. And gay.

[Valik]

I do so enjoy it when people who have only client/server knowledge of COM try to point out the problems in the logic of people who know how to implement COM. No wait, I don't enjoy it at all. It's rather annoying when people who know less than you try to tell you how something should work.

Here's a thought, people? Listen to the developers of this language when we explain something to you. We don't have a history of lying to you so there's no real need to question what we say in such a condescending "But you can't be right" manner. It's rather stupid and insulting. If you have so little faith in us that we can't explain something then find another language not developed by your perceived incompetent individuals.

[KaFu]

Wait... did trancexx just call you gay? And dumb?... AND gay?

About the COM issue...

• Point taken, it is as it is and it will not change
• Some people (including me) are just whining because of the speed impairment, what, just by itself, should just be too understandable
• You've got your reasons why you changed the things under the hood
• I remember the discussion between you and trancexx in the MVPs forum, where you yourself first plainly put your heels into the ground
• And then (for sure your discussion went on via PM before) suddenly you agreed with her
• So there's just a hell of a fucking lot of facts not know to THIS audience
• My vote: Just put it on the things NOT to be (re-)implemented and the discussion's over.
• Given all said and done, thanks to both of you for putting some much effort into this!
• Cause even if I don't see why, I DO trust that you've got your reasons.

But Wait... did trancexx just call you gay? And dumb?... AND gay? Oh... I've asked that already ...

[Valik]

• Some people (including me) are just whining because of the speed impairment, what, just by itself, should just be too understandable

It's fine to question it. But when we explain the choices are "slower speed" and "not working" then that's the point where everybody should shut up and be like, "Yeah, having something that works is far more important than something that's fast but is broken". That didn't happen.

• I remember the discussion between you and trancexx in the MVPs forum, where you yourself first plainly put your heels into the ground
• And then (for sure your discussion went on via PM before) suddenly you agreed with her

This is only tangentially related to her InterfaceDispatch. Okay, more than tangentially. We did have further discussions about InterfaceDispatch via PM which convinced me to allow it to go in. Without that she wouldn't have had current editions of one of the main COM files. Having those files allowed her to see the problems in AutoIt's implementation which was causing some things not to work and she was able to fix it (eventually).

• So there's just a hell of a fucking lot of facts not know to THIS audience

Here's the key fact, though: We do know the facts and we've told you guys what you need to know but that's apparently not enough for some people. Beyond that, though, there's always this: When a developer of a product tells you not to use something and why you shouldn't use it... it's probably best to fucking listen to them, especially when said developer (me) does not have a reputation for bullshitting people. That alone should be enough to silence all of you but I went beyond that and explained (along with trancexx) some of the more technical reasons.

• My vote: Just put it on the things NOT to be (re-)implemented and the discussion's over.

I don't rule out that it will get faster. I only assert that it is unlikely to ever be as fast as it used to be. We've already discussed her re-writing COM from scratch doing things right in all places (Rather than these band-aids built on top of other code). I think you can extrapolate the reason I'm holding her back on this if you've paid attention to the MVP forum the past couple weeks. For all I know she already has it done and is just waiting for me to let her commit it.

But Wait... did trancexx just call you gay? And dumb?... AND gay? Oh... I've asked that already ...

I didn't really discuss COM speed directly. My post was a criticism to the people who put so little faith in us as to question us incessantly about a subject we've explained ad nauseum. Your post, however, does explicitly reference the COM speed issue so I think that means you are gay and dumb and gay.

[jchd]

A little difference in speed is unimportant. Progams are not Monte-Carlo randomness sources. If a change is needed to fix potential issues, then it's of course necessary to apply it.

We have a similar (but much worse) issue with consumer-grade hard disks and with network file locking protocols.

Cheap hard disks (i.e. yours or mine) almost all lie about when exactly a block of data is actually stored on oxide. They return "written to platers" status while in fact your precious data is still in the HD cache, even if you requested a flush. They expect that the HD will have enough time to finish flushing its cache should a power failure occur (or during the fall of a mobile drive before it hits the ground with too much speed). SSDs start doing the same, BTW.

On the contrary high-end drives actually wait for the data to be put in oxide before returning the "safe" status (but only when you request this safer behavior). Net result is that the consumer HD is 5x as fast for data writes than the 3x more expensive HD.

The old adage still holds here. Reliable, fast, cheap: choose any two.

Now about network file locking: we don't even have a real choice. Despite what we have been taught and what most of us would tend to believe, there is no, absolutely NO interoperable network file system offering a fully reliable way to lock a remote file or part of it.

Mac OS, Windows, Linux, Unix, Ultrix, ... you name it, none of them offer a 100% 24/7 guarantee that when you request locking this part of that remote file and receive a "that's done, you can proceed, the remote machine firmly holds the lock you requested" answer from your local system, then noone else can violate the lock in question. It works 99.999999999999999% of the times but there are still obscure situations that cause some layer to fail its invariant.

The problem here is that you as a programmer have no B plan to get around this sad situation. You gamble on the whopping 99.99999999999999999% and hope that it will work "long enough".

For that there is a new adage. Unreliable, fast: pick both.

Both above issues are terrible for lite database engines (like SQLite you know?) which don't have a client/server architecture. That's why it is a gamble to place an SQLite DB on a share.

In view of such problems, I regard a few percent of speed gained or lost the same way I watch stock values highs and lows.

I'd happily exchange todays machines/OSes for 486 PCs with fully reliable hard/soft context.

Dumb I kow I'm already. Now call me gay I don't care (and it's hardly an insult). I don't even know myself: I never tried

[dv8]

Sorry jchd, but 25times = 2500% slow down is hardly called "a few percent". (see my previous posts in this thread with the timed examples) And the way you watch stock values highs and lows, highly depends on what stocks you have in your "wallet"... Don't you agree?

I'm dumb, I know. Call me gay if you want, I don't care! I know nothing about the ATL (OK now I know a few things because I googled it), but 2500% is a HUGE speed drop. I think this is just UNREAL. In my experience (which is not big, but still...) such delays are often caused by letting the loops loop away a few more times even if they have finished their job, or if someone forgot to remove an occasional timeout, put there for testing purposes.

I only ask the developers to spare a few minutes and revise their code and do some time tracking to see what is causing these huge unreal delays. Don't get me wrong, I've already accepted the speed drop and I agree with you that the "right way" is better than the "fast way". It is just that the "right way" is unbelievably slow.

Thanks guys! I mean no harm!

[Ascend4nt]

Noone here should be concerned with what ATL means - that was the point of my post. That just happens to be a programming framework in C++ for COM objects, and its nothing a typical AutoIt programmer would know about, nor should they know about it as nothing in their scripts will need to change. I happen to know about STL because its been part of Microsoft C++ compilers since the 90's. (I've been programming in C++ on the side for 20 years) So, there's nothing 'new' about ATL, just the way its implemented in each succeeding release.

The fact is however, as an AutoIt scripter, your code will remain the same. The objects you access will be the same. The only thing changing is AutoIt's code base. They are changing it to work as it should have (as has been stated). I can certainly understand that, and even support it (its not good practice to leave bugs in code). What I had issues with was the misleading comments on new secure ATL objects causing slowdowns. Those same objects are currently being used in the production version of AutoIt. Only the base code is changing (again, to fix some issues in AutoIt's implementation). That's all anyone really needed to know. ATL should never have been mentioned. Having been described the way it was just served to confuse people.

Edited November 4, 2011 by Ascend4nt

[wraithdu]

I only ask the developers to spare a few minutes and revise their code

Oh no you didn't... <insert missing popcorn smiley>

[Valik]

In my experience (which is not big, but still...) such delays are often caused by letting the loops loop away a few more times even if they have finished their job, or if someone forgot to remove an occasional timeout, put there for testing purposes.

I only ask the developers to spare a few minutes and revise their code and do some time tracking to see what is causing these huge unreal delays. Don't get me wrong, I've already accepted the speed drop and I agree with you that the "right way" is better than the "fast way". It is just that the "right way" is unbelievably slow.

Do you read the things I write? Do you read the things you write? I've already explained at least twice now that the speed may be improved in the future. What more do you want? Should I delay the release of 3.3.8 by 6 months just so a few ungrateful whiny bitches who know fuck all about programming can have their precious "fast" COM code?

If you do not like how the current version of COM works then use another language.

Noone here should be concerned with what ATL means - that was the point of my post. That just happens to be a programming framework in C++ for COM objects, and its nothing a typical AutoIt programmer would know about, nor should they know about it as nothing in their scripts will need to change. I happen to know about STL because its been part of Microsoft C++ compilers since the 90's. (I've been programming in C++ on the side for 20 years) So, there's nothing 'new' about ATL, just the way its implemented in each succeeding release.

The fact is however, as an AutoIt scripter, your code will remain the same. The objects you access will be the same. The only thing changing is AutoIt's code base. They are changing it to work as it should have (as has been stated). I can certainly understand that, and even support it (its not good practice to leave bugs in code). What I had issues with was the misleading comments on new secure ATL objects causing slowdowns. Those same objects are currently being used in the production version of AutoIt. Only the base code is changing (again, to fix some issues in AutoIt's implementation). That's all anyone really needed to know. ATL should never have been mentioned. Having been described the way it was just served to confuse people.

It is clear to me that you either did not read all of my post(s), you failed to understand them or you are willfully misconstruing what I said. I'm not sure how you find it misleading when I give what is essentially a high-level overview of the implementation details of the problem and solution. Secure versions of ATL are the cause. The changes to AutoIt are the effect.

Do not fuck with me on this subject any more. If all I can expect for all the hard work trancexx has put into getting COM working right is a bunch of bitching I will remove COM from the next version of AutoIt. I suggest all of you shut the fuck up and see what happens rather than being incessantly annoying about it. If any of you think this is a hollow threat then push me and you will see a new beta without COM within an hour of me seeing your post. I suggest none of you waste my time in pursuing this.

End subject unless another developer has something else to say.