MSIME support causing slow setup until explorer.exe paused?
I tried installing StarUML (after doing winetricks vcrun6 msxml3, as required), and the setup crept along very slowly... so I got curious and ran top. Most of the cpu time was being used by Explorer and wineserver, and interestingly, if I suspended Explorer by doing strace -p <pid of explorer> and then pressing ^S, the install ran awful darn fast. So, what was explorer doing that was slowing things down so much? writev(3, [{"l\0\0\0\30\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0S\0e\0r\0v\0i\0c\0e\0", 24}], 2) = 88 ... writev(3, [{"l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0O\0p\0"..., 42}], 2) = 106 ... writev(3, [{"l\0\0\0&\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0M\0o\0u\0s\0e\0O\0p\0e\0r\0a\0t\0"..., 38}], 2) = 102 ... writev(3, [{"l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0R\0e\0"..., 42}], 2) = 106 ... This persisted in the app, too, not just in the installer. So it kind of sounds like our msime support is hurting us performance-wise? - Dan
Humm, MSIMEService, MSIMEReconvertOptions, MSIMEMouseOperator, etc... those are all Messages that Microsoft Office looks for and sends to the IME during operations. For the most part all those messages are just stubbed. The messages are Registered in Imm32/imm.c once per process, and also registered in winex11.drv/ime.c also once per process. I am pretty sure we do not send those messages somewhere. So I am not sure why they would be taking up so much cpu time. Do you know what is happening with the messages during the slow-down? thanks, -aric Dan Kegel wrote:
I tried installing StarUML (after doing winetricks vcrun6 msxml3, as required), and the setup crept along very slowly... so I got curious and ran top. Most of the cpu time was being used by Explorer and wineserver, and interestingly, if I suspended Explorer by doing strace -p <pid of explorer> and then pressing ^S, the install ran awful darn fast.
So, what was explorer doing that was slowing things down so much?
writev(3, [{"l\0\0\0\30\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0S\0e\0r\0v\0i\0c\0e\0", 24}], 2) = 88 ... writev(3, [{"l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0O\0p\0"..., 42}], 2) = 106 ... writev(3, [{"l\0\0\0&\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0M\0o\0u\0s\0e\0O\0p\0e\0r\0a\0t\0"..., 38}], 2) = 102 ... writev(3, [{"l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0R\0e\0"..., 42}], 2) = 106 ...
This persisted in the app, too, not just in the installer.
So it kind of sounds like our msime support is hurting us performance-wise? - Dan
On Mon, Apr 21, 2008 at 5:12 AM, Aric Stewart <aric(a)codeweavers.com> wrote:
MSIMEService, MSIMEReconvertOptions, MSIMEMouseOperator, etc... those are all Messages that Microsoft Office looks for and sends to the IME during operations. For the most part all those messages are just stubbed.
The messages are Registered in Imm32/imm.c once per process, and also registered in winex11.drv/ime.c also once per process. I am pretty sure we do not send those messages somewhere. So I am not sure why they would be taking up so much cpu time.
Do you know what is happening with the messages during the slow-down?
Oddly, they don't seem to be happening on Dapper. I'll try again on Gutsy tonight. (Chris Smith says he saw something like this with iTunes on gentoo today, too.)
On Mon, Apr 21, 2008 at 1:59 PM, Dan Kegel <dank(a)kegel.com> wrote:
MSIMEService, MSIMEReconvertOptions, MSIMEMouseOperator, etc... those are all Messages that Microsoft Office looks for and sends to the IME during operations. For the most part all those messages are just stubbed.
The messages are Registered in Imm32/imm.c once per process, and also registered in winex11.drv/ime.c also once per process. I am pretty sure we do not send those messages somewhere. So I am not sure why they would be taking up so much cpu time.
Do you know what is happening with the messages during the slow-down?
Oddly, they don't seem to be happening on Dapper. I'll try again on Gutsy tonight. (Chris Smith says he saw something like this with iTunes on gentoo today, too.)
Not happening on the original machine anymore, either. If I catch it acting up again, I'll get a better log.
I've just had something similar. Tried running a game (I think it was the first time I ran wine in this session), and suddenly system became sluggish. wineserver and explorer were sitting at 50+% and 40+% cpu respectively. Even after I killed the game. strace -p on explorer was also showing lots of these writes. writev(3, [{"l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0R\0e\0"..., 42}], 2) = 106 read(4, "\0\0\0\0\0\0\0\0\3\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) and other stuff like that (registry keys). Any specific steps that can be taken to narrow it down? This is unfortunately kind of random and not readily reproducible, after killing wineserver I don't see this any more. Dan Kegel wrote:
On Mon, Apr 21, 2008 at 1:59 PM, Dan Kegel <dank(a)kegel.com> wrote:
MSIMEService, MSIMEReconvertOptions, MSIMEMouseOperator, etc... those are all Messages that Microsoft Office looks for and sends to the IME during operations. For the most part all those messages are just stubbed.
The messages are Registered in Imm32/imm.c once per process, and also registered in winex11.drv/ime.c also once per process. I am pretty sure we do not send those messages somewhere. So I am not sure why they would be taking up so much cpu time.
Do you know what is happening with the messages during the slow-down?
Oddly, they don't seem to be happening on Dapper. I'll try again on Gutsy tonight. (Chris Smith says he saw something like this with iTunes on gentoo today, too.)
Not happening on the original machine anymore, either. If I catch it acting up again, I'll get a better log.
participants (3)
-
Alexander Dorofeyev -
Aric Stewart -
Dan Kegel