Modify

Opened 9 years ago

Closed 7 years ago

#2002 closed Bug (Rejected)

Try to find the cause of slow file operations.

Reported by: Valik Owned by:
Milestone: Component: AutoIt
Version: 3.3.7.14 Severity: None
Keywords: Cc:

Description

File operations inexplicably took a turn for slow performance. This is a reminder to myself to investigate the issue. The discussion thread can be found here.

Attachments (0)

Change History (9)

comment:1 Changed 9 years ago by Valik

Note to self: Start checking revisions beginning with 5490.

comment:2 Changed 8 years ago by Shaggi

The cause is simple, your old autoit relied on buffered i/o operations while your new doesn't. This means small filewrites done a lot of times (on usual c, buffer is 4k bytes) is a lot quicker than unbuffered. However, for sizes > 4k bytes, pure winapi is bound to be quicker.

You can read about it here: http://www.codeguru.com/forum/archive/index.php/t-228554.html

comment:3 follow-up: Changed 8 years ago by trancexx

How would you know what AutoIt relies on?

Maybe AutoIt currently uses 64kB buffer. Prior mentioned revision it was CRT's choice for default read/write modes. Then it could have been set to 32kB and eventually to current value.
That can be the cause, but it's not something that's simple.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 8 years ago by Shaggi

Replying to trancexx:

How would you know what AutoIt relies on?

Maybe AutoIt currently uses 64kB buffer. Prior mentioned revision it was CRT's choice for default read/write modes. Then it could have been set to 32kB and eventually to current value.
That can be the cause, but it's not something that's simple.

Obviously i dont, but valik mentioned that you switced from crt to winapi. Size of the buffer is ofcourse relevant, but i do believe the cause is the switch from usermode buffering to raw os calls. Every test in these threads show, that it is most likely

comment:5 in reply to: ↑ 4 ; follow-up: Changed 8 years ago by trancexx

Replying to Shaggi:

Obviously i dont, but valik mentioned that you switced from crt to winapi. Size of the buffer is ofcourse relevant, but i do believe the cause is the switch from usermode buffering to raw os calls. Every test in these threads show, that it is most likely

"Usermode buffering"?
Where else could AutoIt be buffering? Shaggi you don't make sense now or I'm missing your point completely.

comment:6 in reply to: ↑ 5 Changed 8 years ago by anonymous

Replying to trancexx:

Replying to Shaggi:

Obviously i dont, but valik mentioned that you switced from crt to winapi. Size of the buffer is ofcourse relevant, but i do believe the cause is the switch from usermode buffering to raw os calls. Every test in these threads show, that it is most likely

"Usermode buffering"?
Where else could AutoIt be buffering? Shaggi you don't make sense now or I'm missing your point completely.

Usermode = opposite of kernelmode. The crt resides in usermode, which is where the buffering happens.. That should make sense? The point was (based on your comments) that you switched from buffered io to unbuffered io, which evidently carries a loss in speed for small operations.

comment:7 Changed 8 years ago by trancexx

No it doesn't.
Who mentioned unbuffered stuff?

Anyway, thanks for the hint.

comment:8 Changed 8 years ago by Valik

Yes, because we totally turned off buffered I/O and I'm a complete moron and missed it. Except for the fact that there's no code explicitly changing anything to do with buffering. Indeed, I also eliminated the switch from CRT to WinAPI as being the cause so any internal buffering differences are already irrelevant.

comment:9 Changed 7 years ago by Jon

  • Resolution set to Rejected
  • Status changed from new to closed

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.