English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   support.WinUAE (https://eab.abime.net/forumdisplay.php?f=5)
-   -   super-slow WinUAE (https://eab.abime.net/showthread.php?t=96718)

jotd 16 March 2019 10:20

super-slow WinUAE
 
Hi,

I don't know why but I noticed that WinUAE was very slow a few months ago.

I don't think it's a regression or something, because already happened with 4.1. Not sure what I changed or what changed but:

at boot, CPU can go up to 600% even more
when playing games (at A500/A1200 speed) sound is choppy, cpu rises to 200%.
Even basic configurations crawl.

ATM I've booted my configuration (JIT/68060) and without doing anything, the cpu is 600%.

I've got a i5 and it used to work all right (cpu below 100%). I thought that some obscure feature was enabled (like video capture or log to file) but it isn't.

I also noticed that using breakpoints (with the debugger) makes WinUAE even slower.

So ATM I don't care too much since I use it to debug games/whdload slaves/other CD32 stuff, but it's beginning to become annoying. It worked so well before, on the same machine.

Would it help to up the priority? My CPU load okay on the machine (not above 7/8%).

Sorry if this is vague, but I'm running out of ideas here.

Toni Wilen 16 March 2019 11:28

Usual basic debugging required: switch options and finally switch it off until something changes (switch sound modes, switch it off, switch DD/D3D9/D3D11 modes, windowed, fullscreen, CPU Idle off, JIT off).

Breakpoints slow down which is normal because each executed instructions full state is stored in circular buffer.

AMIGASYSTEM 16 March 2019 11:45

Toni excuses me for quoting here, but lately I've noticed a detail, I don't know if it depends on external factors or on my systems. When I edit a text or delete or copy a file, if I restart the system immediately then I can't find the changes. I specify that I don't use the PFS filesystem that had this problem also on Amiga 4000 Real, the filesystem I use is SFS

EDIT

Excuse me again Toni, I noticed that on clean systems (standard workbench) this does not happen, probably in complex systems or the Filesystem SFS there is some software that creates this problem.

jotd 16 March 2019 11:49

I'm pretty sure something changed on my system and it's not WinUAE fault. I'll check the video/audio options, looks like a good start. thanks Toni.

AMIGASYSTEM 16 March 2019 12:27

I have not found any difference in speed on the various Amiga systems I use, maybe your problem may be due to Windows, have you changed some hardwiring component lately?

Toni Wilen 16 March 2019 12:33

Please, do not post random guesses (or off topic problems). It is quite obvious something has changed.

jotd 16 March 2019 16:31

Well, I've tried disabling sound, changing draw mode to ddraw, 9, 11, changing triple buffering to double, nothing helps. It's just horrible. CPU up to 800% sometimes 1000%...

I quit WinUAE and restarted with the same exact configuration and now it works fine.

I think the CPU regulation has an issue. Like if WinUAE was "waiting". Well. I don't understand, I just played Desert Strike and worked perfect. Just before quitting, it was horrible.

Okay, sorry, can't say more ATM.

mark_k 16 March 2019 17:11

Which version of Windows are you using?

jotd 16 March 2019 17:14

- Vista
- We're dead

no, it was a joke, I'm using Windows 10

Toni Wilen 16 March 2019 17:20

Try mapping input event "Disable screen updates" to some key using Input panel.

Does it still run as slowly as before if you press mapped key when running something that uses native mode and plays music?

jotd 16 March 2019 18:31

I'll try it out when the problem comes back. I had this issue for weeks. I suppose that some process in the background is interacting in some way...

Toni Wilen 16 March 2019 19:22

Capture also log when the problem happens (start with logging enabled, wait few seconds of slow boot, quit), attach winuaelog.txt.

malko 01 November 2019 14:38

Was not sure to open a new thread, but decided to post here finally. Please note, my problem is now solved. Don't know if it will last but is't seems solved.

I had quite a similar problem yesterday evening (WinUAE 4.0.1).

WinUAE took up to 55 seconds to load :guru (from double click on icon up to the display of the interface) - (WinUAE install containing the 'DDWC'). Loading a game used ~250%/300% CPU.

Yesterday evening, in addition, after a WinUAE restart, NONE of the ArtImages were displayed :shocked . If I clicked on 'Load' the right panel was flashing once (appears & disappears) :confused.

I thus decided to backup my winUAE.ini & reg entries and delete them (the ini & reg entries).

After a reboot, I setted "portable mode", quitted, deleted some MRUList in the ini and reloaded and quitted again (to be sure changes were saved in the ini).
I then have manually edited the ini to define GUI size, etc. (to fit my old configuration).

Now everything is running well. Even WinUAE loads (the DDWC) in 4 seconds !!! :lol

Don't say it's the solution for everyone but hope it may helps others facing slowdowns.

Toni Wilen 01 November 2019 17:49

Sounds like data that gets loaded at config load (rom images, boxart stuff if enabled, floppy images, harddrives etc) pointed to non-existing network path or similar. It can easily cause long delays.

Almost certainly nothing in common with OPs problem :)

malko 01 November 2019 19:43

I have to admit that the "super-slow WinUAE" was maybe the only point in common here.
My use of WinUAE seems a bit different from jotd ;)

Joke apart, except some entries pointing to removable USB devices (same USB stick but with different letters), I didn't see anything unusual in the ini.
What is strange, if it's related to the slowness, is that these entries were in the "HardFileMRUList" parts (history of used path if I am correct ?).

Edit: forgot to mention that I always use relative path, so seeing drive letters is strange.


All times are GMT +2. The time now is 05:48.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.04376 seconds with 11 queries