Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Know what you're using. Size of some common types.
Know what you're using. Size of some common types. [message #57902] Mon, 27 December 2021 19:33 Go to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Test result

index.php?t=getfile&id=6553&private=0

Now I have redone the test in Release mode, the result is not as eye-catching.

Event<> is of the same size as void *, this is better than I had expected. Of course actual memory used might be more than that: a thisfn with the sizeof of member function pointer and an object pointer for this will have difficulty to fit in the room for a void *.

Using 64 bit for context. I would think a ScrollBar is too big for the job it does. Ideally it should be done without containing 4 Buttons or Button should somehow be compacted to use significantly less room and leave some functions to derived class or optionally(pay per use) memory allocated from heap.

Anyway, the result is quite satisfying and reassuring.

BTW, test program:
#include <CtrlLib/CtrlLib.h>
#include <GridCtrl/GridCtrl.h>
#include <TabBar/TabBar.h>

using namespace Upp;
#define SZ(t) "\n"#t"\t" << sizeof(t) /*<<"\t"<<alignof(t)*/

GUI_APP_MAIN
{
	String s;
	s	<< SZ(void *)
		<< SZ(Value)
		<< SZ(String)
		<< SZ(Event<>)
		<< SZ(Vector<int>)
		<< SZ(Button)
		<< SZ(EditField)
		<< SZ(ScrollBar)
		<< SZ(TabBarCtrl)
		<< SZ(ArrayCtrl)
		<< SZ(GridCtrl);
	RLOG(s);
}
  • Attachment: a.png
    (Size: 21.55KB, Downloaded 498 times)

[Updated on: Mon, 27 December 2021 20:42]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57903 is a reply to message #57902] Mon, 27 December 2021 19:58 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1077
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Lance,

Could you tell us more what is the root cause of your problems? Today, you created several threads about optimization. What is the reason of it? Do you want to write application on some embedded system?

In order to understand Button size problem it would be good to know the size of Ctrl (The class from which all controls inherits) and Pusher (Base class for Button). I am also analyzing ScrollBar code and it seems that for most themes we do not need prev2 and next2 buttons:
Button  prev, prev2, next, next2;

I could imagine themes without buttons (like current KDE one). In this case keeping four buttons on stack seems like a waste. It should be replaced with something like std::optional<Button> (Upp::One):
One<Button> prev, prev2, next, next2;


Klugier


U++ - one framework to rule them all.

[Updated on: Mon, 27 December 2021 19:59]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57904 is a reply to message #57903] Mon, 27 December 2021 20:32 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Hi Klugier:

Thank you for being responsive.

No I am not doing embedding developing. Just out of curiosity. Laughing

Regards,
Lance
Re: Know what you're using. Size of some common types. [message #57905 is a reply to message #57904] Mon, 27 December 2021 20:37 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
BTW, theming is something I almost have 0 knowledge. Any suggestion on which part of uppsrc or examples/references/tutorials etc, I should take a first look at?
Re: Know what you're using. Size of some common types. [message #57909 is a reply to message #57905] Mon, 27 December 2021 21:42 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1077
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Lance,

You should read documentation page about Chameleon. You could find it here. Code sample could be find in reference/Chameleon.

Klugier


U++ - one framework to rule them all.

[Updated on: Mon, 27 December 2021 21:44]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57911 is a reply to message #57909] Tue, 28 December 2021 02:29 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Thanks, Klugier! It's going to take me a while to digest the materials.
Re: Know what you're using. Size of some common types. [message #57914 is a reply to message #57911] Tue, 28 December 2021 05:17 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1363
Registered: December 2006
Ultimate Contributor
It is possible to reduce size of data structures by eliminating padding gaps ...

Regards,
Novo
Re: Know what you're using. Size of some common types. [message #57931 is a reply to message #57914] Tue, 28 December 2021 20:27 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Novo:

By moving similarly algined items together (combined two seperated bitfield section, and move int8 item together with them)
	int8    push;
	int8    light;
	bool    horz:1;
	bool    jump:1;
	bool    track:1;
	bool    autohide:1;
	bool    autodisable:1;
	bool    is_active:1;

We can save like 16 bytes on 64 bit platform. If we try harder, like declaring linesize, etc as int8, we can save some more bytes. But these are all marginal.

What I have in mind is to get rid of the 4 Buttons completely. That way we can save around 1K in each ScrollBar object. ScrollBar is definitely a class that is worth rewritten. The rewriting work might even not be too difficult.

Here is a function from ScrollBar.cpp
int  SkrollBar::GetMousePart()
{
	int q = -1;
	for(int i = 2; i >= 0; i--)
		if(HasMouseIn(GetPartRect(i))) {
			q = i;
			break;
		}
	return q;
}

The slider area is divided into 3 parts, the upper blank area, the slider button, the bottom blank area. We can divide it into 5(or seven), with addition to accomodate prev,next (and even prev2, next2: anybody can ecudate me on what these two buttons are doing? I don't see it on the GUI at all)

These kind of refinement do not add functionalities but still contribute to a better U++ experience.

[Updated on: Tue, 28 December 2021 20:36]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57933 is a reply to message #57931] Tue, 28 December 2021 23:49 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1363
Registered: December 2006
Ultimate Contributor
If one is allocating millions of inefficiently aligned structures, then he/she is wasting a lot of memory.

BTW, there are tools which visualize amount of wasted memory caused by inefficient alignment of data.


Regards,
Novo
Re: Know what you're using. Size of some common types. [message #57934 is a reply to message #57933] Wed, 29 December 2021 01:42 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Agreed. Here the waste on suboptimal alignment (or possible gain by rearrange member vars to arrive at the least waste on padding) is insignificant comparing to the size of the object(of the class).

I do believe we should pay some more attention to the order we declare struct/class member variable to arrive at more efficient memory usage. I come across bitfields separated by other type of variable once in a while. The ScrollBar class is an example of this.
private:
	int     thumbpos;
	int     thumbsize;
	bool    horz:1;
	bool    jump:1;
	bool    track:1;
	int     delta;
	int8    push;
	int8    light;

	Button  prev, prev2, next, next2;
	int     pagepos;
	int     pagesize;
	int     totalsize;
	int     linesize;
	int     minthumb;
	bool    autohide:1;
	bool    autodisable:1;
	bool    is_active:1;


But this are overall of a less degree of concern. The percentage saving is usual immaterial.
Re: Know what you're using. Size of some common types. [message #57940 is a reply to message #57934] Thu, 30 December 2021 02:39 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
I manage to create a ScrollBar twin (SkrollBar) that should look and act exactly the same (to be safe, I leave untouched some old code that could benifit from rewritten with new facilities but I am not very sure yet).

Class		Size
-------		-----
Button		224
SkrollBar	232
ScrollBar	1136
TabBarCtrl	1000
ArrayCtrl	3752
GridCtrl	4904
See above table. SkrollBar is now almost same size of Button. Above size of GridCtrl is after both ScrollBar objects in it has been redefined as of type SkrollBar. Imagine howmany GridCtrl/ArrayCtrl you will be using in your program Laughing

The code is still very rough. I dare not to touch the original Slider() portion's Paint & mouse event (I wasn't able to understand it very well). I figure, push and light can be do without, linesize and minthumbsize will be more than enough with an int8. I haven't tries (removing light and push will require rewriting some code), chance is we can get SkollBar of the same size of Button.

Attached is a test that use ScrollBar/SkrollBar Vert()/Horz() side by side. They should look the same and behave the same. The Outer ones are SkrollBar. They respond to MouseMove in debug mode to report the section number that the mouse is currently in.

With a vertical SkrollBar, section 0 is the prev button, section 2 is the prev2 button (mostly invisble), section 3 is the portion of slider above the thumb, section 4 is the thumb, section 5 is the portion of slider under the thumb, section 5 is the next2 button (mostly invisible), section 6 is the next button.

[Updated on: Fri, 07 January 2022 19:10]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57944 is a reply to message #57940] Fri, 31 December 2021 19:51 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
A more presentable state, see attached zip file. Now sizeof(ScrollBar)=sizeof(Button).

Please make a copy of your existing uppsrc/CtrlLib/ScrollBar.*, and and unpack the zip file to overwrite existing ScrollBar.{h,cpp} in the uppsrc/CtrlLib folder. The revision is transparent to library users. Your program should feel no difference, except some savings on executable size and for each ScrollBar object you used, you will save around 900 bytes of memory.
Re: Know what you're using. Size of some common types. [message #57945 is a reply to message #57944] Fri, 31 December 2021 20:20 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
In the spirit of previous discussion with Novo, the following minor change to CtrlCore/CtrlCore.h should decrease the sizeof(Ctrl) and that of all its derivative by 8 bytes on a 64-bit platform. While on 32-bit system there is no gain(Ctrl has been perfectly fine tuned for 32-bit platform), and there should be no penalties either.

Current code:
	Top         *top;
	int          exitcode;

	Ctrl        *prev, *next;
	Ctrl        *firstchild, *lastchild;//16
	LogPos       pos;//8
	Rect16       rect;
	Mitor<Frame> frame;//16
	String       info;//16
	int16        caretx, carety, caretcx, caretcy;//8

	byte         overpaint;


Proposed change:
	Top         *top;

	Ctrl        *prev, *next;
	Ctrl        *firstchild, *lastchild;//16
	LogPos       pos;//8
	Rect16       rect;
	Mitor<Frame> frame;//16
	String       info;//16
	int16        caretx, carety, caretcx, caretcy;//8

	int          exitcode; // move the line here

	byte         overpaint;


After the change, sizeof(Ctrl) is reduced from 152 bytes to 144 bytes on 64bit platform (both MSBT22x64 and CLANG64), while on 32bit platform, it remains unchanged with CLANG, but increases by 8 bytes with MSBT22. This increase is unexpected. If anybody can explain it or figure out a way to avoid it, it will be fully appreciated.

@mirek or @klugier, please consider apply the change after identifying and fixing the unexpected behavior with MSBT. The change is too simple to have potential danger and will affect all objects of Ctrl and its derivatives.
index.php?t=getfile&id=6558&private=0

PS: By making use of MSC 32 bit flag _M_IX86, the above problem could be circumvented as follows:
...
	Top         *top;
#if defined(_M_IX86) // 32bit MSC compiler
	int			exitcode;
#endif

	Ctrl        *prev, *next;
	Ctrl        *firstchild, *lastchild;//16
	LogPos       pos;//8
	Rect16       rect;
	Mitor<Frame> frame;//16
	String       info;//16
	int16        caretx, carety, caretcx, caretcy;//8

#if !defined(_M_IX86)
	int          exitcode;
#endif
	byte         overpaint;

	bool         unicode:1;

	bool         fullrefresh:1;

	bool         transparent:1;
	bool         visible:1;
	bool         enabled:1;
	bool         wantfocus:1;
	bool         initfocus:1;
	bool         activepopup:1;
	bool         editable:1;
	bool         modify:1;
	bool         ignoremouse:1;
...
  • Attachment: a.png
    (Size: 11.67KB, Downloaded 388 times)

[Updated on: Fri, 31 December 2021 22:57]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57946 is a reply to message #57945] Fri, 31 December 2021 20:28 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
And in the same spirit, move
protected:
	bool    monoimg;
	byte    type;

out of class Button, to its base class Pusher, ending with something like
class Pusher : public Ctrl {
public:
	virtual void   CancelMode();
	virtual void   LeftDown(Point, dword);
	virtual void   MouseMove(Point, dword);
	virtual void   MouseLeave();
	virtual void   LeftRepeat(Point, dword);
	virtual void   LeftUp(Point, dword);
	virtual void   GotFocus();
	virtual void   LostFocus();
	virtual void   State(int);
	virtual String GetDesc() const;
	virtual bool   Key(dword key, int);
	virtual bool   HotKey(dword key);
	virtual dword  GetAccessKeys() const;
	virtual void   AssignAccessKeys(dword used);

private:
	bool    push:1;
	bool    keypush:1;
	bool    clickfocus:1;
protected:
	bool    monoimg;
	byte    type;


Should not harm Pusher but decrease sizeof(Button) and that of its derivatives by 8 bytes on 64-bit platform and 4 bytes on 32-bit platform.

The changes are too trivial to be of danger.
Re: Know what you're using. Size of some common types. [message #57961 is a reply to message #57902] Wed, 05 January 2022 10:47 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
BTW, there are two benchmarking packages for this purpose already:

benchmarks/sizeof

bemchmarks/sizeof_gui

Anyway, this is definitely a good effort! Keeping sizeof(Ctrl) low is important.

Mirek
Re: Know what you're using. Size of some common types. [message #57974 is a reply to message #57961] Fri, 07 January 2022 17:25 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
mirek:

Thanks. The output from above test program works better with Excel like utility so that record keeping and comparison are easier.

While there will not be a fixed ratio between total Ctrl used and that of ScrollBar used, I have test run some examples to get a feel of a rough ratio.

Examples/AddressBook(Up to the mainwindow is open): Max Ctrl Used: 96, Max ScrollBar used: 11 (9:1)

Examples/HomeBudget(Up to the mainwindow is open): Max Ctrl Used: 277, Max ScrollBar used: 22 (13:1)

Reference/GridCtrlTest(Up to the maindown is open): Max Ctrl Used: 1011, Max ScrollBar used: 132 (8:1)

UppSrc/ide(open a blank CtrlLib application): Max Ctrl Used: 802, Max ScrollBar used: 217 (4:1);

Again ide, but this time open UppSrc/ide, and in it, click the very last file ide.lay: Max Ctrl Used: 22001, Max ScrollBar used: 2181 (10: 1)

Considering the absolute and percentage saving we derived from the new implementation of ScrollBar (well, only an insignificant part of it to be more precise), accepting new ScrollBar would be as beneficial as compacting Ctrl, if not more: mirek mentioned in another discussion that he could replace a String with a const char *, resulting in additional saving of 8 bytes on 64 bit platforms and 12 bytes on 32 bit ones. Combining with that derived from rearranging member variables to minimize padding, we end up with 16 bytes each on both 32 and 64 bit platforms. That's about it if we don't want to lose any functionalities.

ScrollBar is pretty isolated: I don't think many people will need to derive from it. As long as we maintain the user interface stable/untouched, and test it on different platforms/settings, it should pose very low risk of messing up things (to replace it). These are all gain at no cost: by the way, new ScrollBar results in smaller executable too. Now my question is: Why not? Razz

----
PS: Even if you derive from ScrollBar, I don't think you will be affected: the functions/member variables changed are all private (as far as I can remember).

[Updated on: Fri, 07 January 2022 18:41]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57975 is a reply to message #57974] Fri, 07 January 2022 17:44 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Assuming the proposed data reorganization for Ctrl and Pusher & Button are both applied, sizeof(Button) will be reduced 16 bytes from 224 to 208 (on 64bit platforms). By ridding of the 4 contained Buttons, each ScrollBar object will be using 4x204=832 less bytes.

Use second case of uppsrc/ide on 64 bit platform for example, compacting Ctrl to save 8 bytes each will have a total memory saving of 22001x8=176,008 bytes. The new ScrollBar implementation will have an incremental memory saving of 2181x832=1,814,592 bytes.

I am not saying 2M or even 10M of memory saving will make much a difference in now-a-days hardware, but reducing sizeof(ScrollBar) to 1/5 of what it is (actually even less) might not be less important than reducing sizeof(Ctrl) by 8 - 24 bytes from practical persperctive.

[Updated on: Fri, 07 January 2022 18:18]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57976 is a reply to message #57974] Fri, 07 January 2022 18:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
Well, I do not want to dive into this now - we need to release soon to stabilise huge changes done and there is a lot of more important things to fix.

Anyway, after that, this is quite important and moreover fun.

The situation with ScrollBar buttons repeats itself in other places, e.g. with SpinButtons. I am thinking there could be some nice generic solution, something like "Buttons" partly abstract class that would represent "embedded buttons" using just virtual methods of derived class (similar fashion to your ScrollBar implementation, but in generic way). EditIntWithSpin is quite big sizeof as well and it is even more important (as it is has higher chance to be used in huge quantities).

But that all is pennies compared to DropList sizeof. That one needs converting PopUpTable list; to One<PopUpTable> list; and only create when needed and then delete. Unfortunately, it is delicate work, a lot of things there could go wrong.

Another things I would like to see reduced is String Ctrl::info. const char * would work there with some effort. 8 bytes saved Smile (Maybe add some flag that it points to Layout ID only, then it could point to character literal in layout widget, even more savings).
Re: Know what you're using. Size of some common types. [message #57977 is a reply to message #57975] Fri, 07 January 2022 18:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
Lance wrote on Fri, 07 January 2022 17:44
Assuming the proposed data reorganization for Ctrl and Pusher & Button are both applied, sizeof(Button) will be reduced 16 bytes from 224 to 208 (on 64bit platforms). By ridding of the 4 contained Buttons, each ScrollBar object will be using 4x204=832 less bytes.

Use second case of uppsrc/ide on 64 bit platform for example, compacting Ctrl to save 8 bytes each will have a total memory saving of 22001x8=176,008 bytes. The new ScrollBar implementation will have an incremental memory saving of 2181x832=1,814,592 bytes.

I am not saying 2M or even 10M of memory saving will make much a difference in now-a-days hardware, but reducing sizeof(ScrollBar) to 1/5 of what it is (actually even less) might not be less important than reducing sizeof(Ctrl) by 8 - 24 bytes from practical persperctive.


Frankly, I am not that concerned about saving memory in such normal situations.

However, I have seen/used ArrayCtrls with thousands of embedded DropLists. There it could be huge....
Re: Know what you're using. Size of some common types. [message #57978 is a reply to message #57977] Fri, 07 January 2022 19:01 Go to previous messageGo to previous message
Lance is currently offline  Lance
Messages: 534
Registered: March 2007
Contributor
Thanks for the feedback, mirek. Please stay focused on important/urgent matters.

And come back to consider these more marginal issues when you have time & interests. Razz

Thank you again for such a great product named Ultimate++. I wish it would stay around as long as there are people using C++. I feel sad that such great work is not as popular as it deserves. I tried (quite hard and persistently) to sell it to my teenage son and his friends but haven't been very successful. More good projects that's written with UPP facilities need to be around to spread its influence. E.g. pgAdminIII could benefit from a better/more responsive GUI. Our community members should be able to come up with better candidates. Downstream demands will also help to find directions of Core Upp development.
Previous Topic: [SOLVED][Question] Is anyone able to build UPP and Binaries based upon it as 32-Bit?
Next Topic: Source Code Efficiency Minor Issue
Goto Forum:
  


Current Time: Sun Jun 16 21:39:23 CEST 2024

Total time taken to generate the page: 0.02779 seconds