Why ReactOS runs so slowly?

[gabrielilardi]

I'd like to further investigate this issye, the following line sounds worrying

Although I'd installed it on real hardware I can watch the buildup of the window elements for a lot of seconds!

I have noticed important delays in 1024x768 in real HW (some time ago), I'll re-test to confirm.

[z180]

I think that I would be able to make an optimized build without the recouces of languages I cant speak and less coloured icons and BMPs
and compiler arguments.I dont recommend doing it here,only as a
private initiative.SVN builds are for testing and have debug enabled.
Also an improvement over windows are the KDBG builds which
have a kernel debugger like BSDs DDB or KGDB.I also think that
reactos could be improved on older hardware like notebooks by testing
and reporting what make problems.File operations like playing
Duke Nukem Forever could be done faster when the cache manager
code arrives that was said to come in 0.3.0 but is not yet ready to use.
Also ReactOS could use something like the UIP stack to boot fast from
network with freeldr.

[Ged]

The svn debug builds shouldn't cause any noticable speed difference. Debug output is limited in standard builds, esspecially in the window drawing code which is where Yellow said the problems were

[gabrielilardi]

Sorry, I can't confirm anything, reactos regressed in my computer, it crashes at the end of 2nd stage:

Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault)
Memory at 0x00000084 could not be read: Page not present.
kdb:> cont

*** Fatal System Error: 0x0000001e
(0xC0000005,0xAD87E379,0xAF49E510,0x00000000)

Entered debugger on embedded INT3 at 0x0008:0x808abf88.
kdb:> cont

!!! Unhandled or Unexpected Code at line: 80af74e7!!!

[GreatLord]

use command bt so we can get a backtrace

[gabrielilardi]

use command bt so we can get a backtrace

Sorry, done:

Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault)
Memory at 0x00000084 could not be read: Page not present.
kdb:> bt
[7hEip:
<win32k.sys:90379 (subsystems/win32/win32k/objects/gdiobj.c:1311 (GDIOBJ_SetOwnership@8))>
Frames:
<win32k.sys:8898d (subsystems/win32/win32k/objects/dc.c:2629 (@DC_SetOwnership@8))>
<win32k.sys:78489 (subsystems/win32/win32k/ntuser/windc.c:598 (@DceFreeDCE@8))>
<win32k.sys:784b1 (subsystems/win32/win32k/ntuser/windc.c:688 (@DceEmptyCache@0))>
<win32k.sys:8a3bb (subsystems/win32/win32k/objects/dc.c:724 (@IntDestroyPrimarySurface@0))>
<win32k.sys:7fac4 (subsystems/win32/win32k/ntuser/winsta.c:327 (@IntEndDesktopGraphics@0))>
<win32k.sys:64ee3 (subsystems/win32/win32k/ntuser/guicheck.c:73 (@RemoveGuiApp@4))>
<win32k.sys:64f57 (subsystems/win32/win32k/ntuser/guicheck.c:94 (@co_IntGraphicsCheck@4))>
<win32k.sys:4c485 (subsystems/win32/win32k/main/dllmain.c:148 (Win32kProcessCallback@8))>
<NTOSKRNL.EXE:7e597 (ntoskrnl/ps/kill.c:697 (PspExitThread@4))>
<NTOSKRNL.EXE:7f115 (ntoskrnl/ps/kill.c:889 (PsExitSpecialApc@20))>
<NTOSKRNL.EXE:132b (ntoskrnl/ke/apc.c:443 (KiDeliverApc@12))>
<NTOSKRNL.EXE:96928 (ntoskrnl/ke/i386/trap.s:285 (KiServiceExit))>
<ntdll.dll:5d03>
<user32.dll:27e2b>
<user32.dll:27f54>
<msgina.dll:161f>
<kernel32.dll:2247e>
<00000000>
kdb:>

[forart]

forart more correct reactos developers don't need to do 3DNow!/MMX/SSE-2-3 optimizations. They are is gcc complier switchs that do them. x64 is waiting on a stable open source complier for windows.

AFAIK manual optimizations are better than compiler ones (that have mutch problems too)...

I'd like to further investigate this issye, the following line sounds worrying

Although I'd installed it on real hardware I can watch the buildup of the window elements for a lot of seconds!

I have noticed important delays in 1024x768 in real HW (some time ago), I'll re-test to confirm.

I noticed too that VBE is mutch compatible (standard-compliant) but not so fast on real HW (i believe that asm optimizations would be useful here).

Last but not least I -still- feel the need of an HW configs database for testers (at least, better for all forum users), that IS useful for better compatibility feedback, IMHO.

[Z98]

There's a reason we don't use assembly, and it's because we want to keep the amount of code we would need to rewrite for ports to a minimum. Assembly by definition isn't portable, and like oiaohm said, compilers these days are extremely good at optimizations. We are not in a situation where hand optimization would serve any purpose.

[PsyDonia]

The version I can install is amaizingly fast.
I boots up in a few seconds.
Wile XP on the same computer boots up in about 2minutes.
Then apps and stuff start way faster than in XP.
For me I have not found anything that is slower in ROS

[oiaohm]

Forart stop following ASM is great logic.

Manual optimization have there own set of flaws. Now lets look at a few simple problems.

i486 pent 1 pent 2 pent 3 and pent 4. Each one of these requires different alignments to get best performance. I am restricting my self to intel chips.

So this now means any manual asm optimization has be coded for every chip to extract the best performance. Note that is not even a instruction list different.

Forart please read you locations you use to back up your point.

From Your wikipedia point

As compiler technologies have improved, good compilers can often generate better code than human programmers

First three points there why complier fail are complier dependent. Yes there are better compliers out there that do a better job.

The forth point of course running optmization passes cost times.

The last one is partly a joke. Early on in complier development getting the order right of opt functions was critical. These days the order is quite well worked out.

Most Asm coders are comparing themselfs to msvc and gcc. Sorry to say these are not the best in existence. Gcc openly admints that it does not have a overall exe optmiser and that one is required. Best compliers out there are really hard to beat on performance. They really only have one flaw they take a fair while to process to produce a exe.

inefficient algorithm inside gcc if its contained to 1 c file and the complier understands what the function is doing will be rewriten.

So trying
int c,b;
void func (){ c=1; b=c *2; }
Now b=c*2 is predictable to be 2 so void func(){c=1;b=2}
I could be doing way way more complex algorithm. The compliers these days are truly looking at it.

So why can ASM coders get smaller and faster than gcc. Its dead simple.
gcc produces .o files then LD goes and tacks them into a exe using only basic optmiztations. Final fault is not the complier is the dam linker. If a asm coder uses LD the same way they are just as stuffed.

[Carlo Bramix]

Although I'd installed it on real hardware I can watch the buildup of the window elements for a lot of seconds!

I use ReactOS with QEMU on a Pentium 4 at 3 GHz for testing.
And I must say, yes, actually I found several slowdowns, like one you said, but I always believed that this was caused by the virtual machine and by the fact that ReactOS does not provide an accelerated video driver, just a generic one, which is probably the same thing that happens on your real hardware.
The experience is really different if you work under VMware, here the accelerated graphic driver do its job and the response seems realtime.

Sincerely,

Carlo Bramini.

[florian]

The version I can install is amaizingly fast.
I boots up in a few seconds.
Wile XP on the same computer boots up in about 2minutes.

As long as you are aware that a "stripped" XP can boot faster, too, and that
within our ReactOS a lot of things are not yet implemented.

Then apps and stuff start way faster than in XP.
For me I have not found anything that is slower in ROS

Just look here as one example (although the posted information might be obsolete.)

[z180]

It has a reason that ReactOS is written mostly in C because there is an
incomplete port to PowerPC CPU (PowerMac?) computers.I do not
know of system requirements but it crashs on booting.Also there
was some work going on to port ReactOS to ARM.

[Haos]

PPC port crashes at boot because its incomplete. Or rather, it doesn`t boot completely because of its incompleteness.

[elhoir]

am i wrong if i say that the only piece of software that is different from an architerture to another is the HAL layer?