Avoiding micro-lag for 64bit context menu?

[Marco]

Would having ContextMenu64.exe constantly running in the background avoid the micro-lag that happens when choosing the 64-bit context menu from the regular menu? If so, would it be a feasible option?

[admin]

Well, currently ContextMenu64.exe constantly running in the background anyway once you have called it. It's removed when XY is removed. So there is a theoretical possibilty to speed things up by communicating with it via WM_COPYDATA instead of calling a new instance each time. But this is Mesh's work not mine.

But, I don't think the lag is bad. It's almost instant over here. It's probably even other things (shell extensions) that make it slow at your place.

[Marco]

Oh, I just saw in Task Manager that ContextMenu64 is loaded together with XY and not with every single context menu call. WM_COPYDATA is the way to go imho. If I remember correctly, you currently write a temp file text containg the path of the desired item and then fire up ContextMenu64, which reads such file and open the menu? Such disk may be the cause. If other shell extensions were the cause, the context menu would not be instant in WE either, right?

[admin]

Right.

But I don't think the disk writing causes a notable lag. Rather calling a 2nd instance of the helper app, which then defers the call to the already running app, or closes the running app (not sure how it is done).

[Filehero]

But I don't think the disk writing causes a notable lag.

Not with a SSD.

[admin]

ALAAF!

It was you who posted at 11:11.

Business closed for today.

[Filehero]

It was you who posted at 11:11.

For once this wasn't on purpose. I hope the hangover is ok.

/e:
- it's around 11 am and no signs from Don -> medium heavy hangover.


Cheers,
Filehero

[40k]

Well, currently ContextMenu64.exe constantly running in the background anyway once you have called it. It's removed when XY is removed. So there is a theoretical possibilty to speed things up by communicating with it via WM_COPYDATA instead of calling a new instance each time. But this is Mesh's work not mine.

But, I don't think the lag is bad. It's almost instant over here. It's probably even other things (shell extensions) that make it slow at your place.

Individual performance varies. My 64-bit menu takes just over 2 seconds to load. But I'm on i3 1.5ghz laptop.

[Enternal]

Yeah performance really is different. Although it's pretty instant for me now ever since I just put together a new computer this month. Which is why I have been gone for most of the time (due to school work as well). It was about time for a new desktop. My desktop before was from 2001. The family desktop is newer from 2007 and primarily used by me but it's upstairs while my room is down stair. My laptop however served me well since 2011 but just thought that it would be a good idea to actually built a new one now. The total cost was actually only $1050 so I think that it's pretty decent price... I think.

8-Core Overclocked AMD FX-8320 4.3 GHz
16GB Ram
Dual Monitor (24 inch)
120GB SSD
1TB Main HDD + 4TB HDD
Backlit Mechanical Keyboard + High Quality Mouse
other stuff

Yeah. I'm bragging but at the same time, XYplorer is working wonderful on it. It feels even better now with the SSD since almost everything it does is almost instant. Only issue is that I still hope that one day XYplorer can fully support Windows 7+ features like libraries, jumplists, and etc.

[michaelbeijer]

Hmm. It's 2015 now and I am getting pretty annoying lags between right-clicking and the context menu appearing (on Windows 7 64-bit on a very fast computer with SSDs and 32GB RAM). Have a look: https://dl.dropboxusercontent.com/u/680 ... icking.mp4

[admin]

Quoting myself from above:

Well, currently ContextMenu64.exe constantly running in the background anyway once you have called it. It's removed when XY is removed. So there is a theoretical possibilty to speed things up by communicating with it via WM_COPYDATA instead of calling a new instance each time. But this is Mesh's work not mine.

So, Mesh is the man to talk to. He is here in the forum once in a while.