Hi
Here are some ideas for optimizing our gdi object code:
1.) When allocating, locking and deleting a gdi object, we pass the global variable GdiHandleTable to GDIOBJ_AllocObj(). Do we really need this? Is there a case where we pass something else? We would only save few cycles here, but if we don't need it...
2.) When allocating a gdi object, we first need to search the list of LookasideLists. My suggestion is to give each gdi object type a constant index in the list and pass that index instead of the object type value. That would require that the table for the object types/sizes/CleanupProc is in sync with the index definitions. This could be achieved by initializing that table on win32k load: InitGdiObjectType(UINT Index, LONG GdiType, ULONG_PTR ObjectSize, GDICLEANUPPROC CleanupProc); Then we only need to make sure, that every index is only there once and add one line for each object in GDIOBJ_iAllocHandleTable to initialize the object type.
3.) ROS makes massive use of gdi object handles. It uses a lot more handles than windows does. That is because every object we use is always inserted into the handle table. This is slow and wastes handle entries, wich are a limited resource. Whenever we need a (temporary) object, we allocate it (find lookaside list, allocate mem, find free entry, lock entry, do some stuff, unlock entry), then in a second call lock it (do some checks, lock entry, return pointer) and at the end unlock it and then delete it. I think we should rewrite the code a little, so that we only create handles, when the object reaches usermode and use pointers to mem objects instead if the objects are kernel mode / temporary only. XXXOBJ_AllocObj(UINT Index) -> allocate an entry from the LookasideList and initialize it. Don't create a handle. XXXOBJ_FreeObj(PVOID pObjBody) -> free the entry from the LookasideList GDIOBJ_CreateHandle(PVOID pObjBody, UINT Index, LONG GdiType) -> create a handle for a given mem object rewrite some XXXOBJ_Xxx apis to deal with pointers to the mem objects instead of handles (see REGION_Xxx apis)
Imo this should result in a big speed increase for several ntgdi/ntuser apis
Regards, Timo
Hi,
I have been reviewing last changes introduced in rbuild to support the powerpc version and I don't understand the new module type "ElfExecutable". Can anyone explain me why is it necessary?
Looking at the source code I can see that this module type is really similar to the "BootLoader" module type (they produce the boot executable) since rbuild already knows the architecture being build I can't see the difference between both
Also , from my point of view the .rbuild files should contain only abstract information about the build process and not particular one about an architecture or a format type to be used , that's rbuild.exe job , produce the apropiate makefile using all the information available.
Marc
On Tue, 4 Sep 2007 14:05:24 +0200 "Marc Piulachs" marc.piulachs@codexchange.net wrote:
Hi,
I have been reviewing last changes introduced in rbuild to support the powerpc version and I don't understand the new module type "ElfExecutable". Can anyone explain me why is it necessary?
Looking at the source code I can see that this module type is really similar to the "BootLoader" module type (they produce the boot executable) since rbuild already knows the architecture being build I can't see the difference between both
Also , from my point of view the .rbuild files should contain only abstract information about the build process and not particular one about an architecture or a format type to be used , that's rbuild.exe job , produce the apropiate makefile using all the information available.
Rbuild definately encodes too much information inside it, and leaves too little for configuration. Also, most of the modules don't use the ARCH setting, so I was reluctant to introduce an architecture switch in rbuild.
I wouldn't be opposed to removing ElfExecutable if you'd help me sort out how rbuild *should* work.
I'd personally like to see hardcoded strings pulled out into properties and the 'if' code made more uniform. Right now, each tag type needs to be made separately conditionable.
I think that if we made a few things more data-oriented, then rbuild would become much easier to adapt.
You are absolutely right, we have to try to avoid using particular or concrete information about the build process on .rbuild files and abstract the maximum possible data. The .rbuild files at the end should be only metadata that describes the source code. With this information plus the context (Environment + Project) rbuild can guess most of the concrete information needed to generate the appropriate makefile.
Regarding the "ElfExecutable" module type IMHO it's not correct because it does not describe a generic module type .It's a concrete solution for a particular problem. If what "ElfExecutable" really does is create a ppc compatible bootloader version you should modify "MingBootLoaderModuleHandle" to accommodate it using an architecture switch as you suggested and even introducing a new attribute, tag or condition if necessary but not a new module type.
From my point of view the main problem with rbuild is that there isn't any
responsible of the subproject. When a developer needs a particular feature he just implements it in its on way which is fine but rbuild is a more or less complex piece of software that needs to be known what leads to copy-paste code, inconsistencies and really FULL of hacks .It is becoming unmaintainable and sooner or later most parts of it will have to be rewriteen.
One small criticism though I would like to actively work on improving rbuild but it's a little discouraging because the patches send to bugzilla usually takes days or even weeks to be applied what leads to merge conflicts if you keep modifying your working copy. I think other developers feel like me. Reactos would get a lot more contributions if the patch reviewing process was faster.
Marc,
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of art yerkes Sent: Thursday, September 06, 2007 8:59 AM To: ReactOS Development List Cc: Marc Piulachs Subject: Re: [ros-dev] Regarding new rbuild module type "ElfExecutable"
On Tue, 4 Sep 2007 14:05:24 +0200 "Marc Piulachs" marc.piulachs@codexchange.net wrote:
Hi,
I have been reviewing last changes introduced in rbuild to support the powerpc version and I don't understand the new module type
"ElfExecutable".
Can anyone explain me why is it necessary?
Looking at the source code I can see that this module type is really
similar
to the "BootLoader" module type (they produce the boot executable) since rbuild already knows the architecture being build I can't see the
difference
between both
Also , from my point of view the .rbuild files should contain only
abstract
information about the build process and not particular one about an architecture or a format type to be used , that's rbuild.exe job , produce the apropiate makefile using all the information available.
Rbuild definately encodes too much information inside it, and leaves too little for configuration. Also, most of the modules don't use the ARCH setting, so I was reluctant to introduce an architecture switch in rbuild.
I wouldn't be opposed to removing ElfExecutable if you'd help me sort out how rbuild *should* work.
I'd personally like to see hardcoded strings pulled out into properties and the 'if' code made more uniform. Right now, each tag type needs to be made separately conditionable.
I think that if we made a few things more data-oriented, then rbuild would become much easier to adapt.