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.
Re: Know what you're using. Size of some common types. [message #57979 is a reply to message #57978] Fri, 07 January 2022 19:26 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
I kind of understand what you intends to do, because I have also thought in that direction. I call it FakeCtrl: Ctrl-like objects that rely on containing Ctrl's Paint(...), LeftDown(...) etc to mimic an actual Ctrl. Problems is, if we want to generalize it, we will need to have almost all state (and hence member variable) a Ctrl has: the saving won't be significant. While a generic solution is hard to come up with, case by case is easy.
Re: Know what you're using. Size of some common types. [message #57981 is a reply to message #57979] Fri, 07 January 2022 22:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Lance wrote on Fri, 07 January 2022 19:26
I kind of understand what you intends to do, because I have also thought in that direction. I call it FakeCtrl: Ctrl-like objects that rely on containing Ctrl's Paint(...), LeftDown(...) etc to mimic an actual Ctrl. Problems is, if we want to generalize it, we will need to have almost all state (and hence member variable) a Ctrl has: the saving won't be significant. While a generic solution is hard to come up with, case by case is easy.


Only for buttons. That is not that hard.

Mirek
Re: Know what you're using. Size of some common types. [message #57986 is a reply to message #57981] Sun, 09 January 2022 20:36 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
If the intended modified Button will continue to be a Ctrl derivative so that it works seamlessly with existing code, the minimum size it will have is sizeof(Ctrl). In this particular situation, the Ctrl member variable LogPos(and maybe more candidates) can be done without, we can reuse it to put a Style * st; and probably WhenPush event variable somewhere else. In any case, the minimum size will be sizeof(Ctrl). The savings won't be quite as good (significantly less than the case when buttons or even frames are ridden of), even though it indeed involves least work and least chance of surprise.

Another way is to define it something like
class FakeButton 
{
public:
   void Paint(Draw& w, Rect& where, Button::Style& style, int state/*normal,hot,pressed,disabled*/);

   Event<> WhenPush;
};


This way sizeof(FakeButton)==sizeof(Event<>)(==sizeof(void*) ), but the effort involved in revising containing Ctrl (ScrollBar, EditWithSpin, DropList, etc)'s Paint,LeftDown,LeftRepeat, etc, will be quite similar to hardcoding each of the Ctrl's method that we need to change to allow the savings to take place.


[Updated on: Sun, 09 January 2022 20:43]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57987 is a reply to message #57986] Mon, 10 January 2022 01:07 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Lance wrote on Sun, 09 January 2022 20:36
If the intended modified Button will continue to be a Ctrl derivative so that it works seamlessly with existing code, the minimum size it will have is sizeof(Ctrl). In this particular situation, the Ctrl member variable LogPos(and maybe more candidates) can be done without, we can reuse it to put a Style * st; and probably WhenPush event variable somewhere else. In any case, the minimum size will be sizeof(Ctrl). The savings won't be quite as good (significantly less than the case when buttons or even frames are ridden of), even though it indeed involves least work and least chance of surprise.

Another way is to define it something like
class FakeButton 
{
public:
   void Paint(Draw& w, Rect& where, Button::Style& style, int state/*normal,hot,pressed,disabled*/);

   Event<> WhenPush;
};


This way sizeof(FakeButton)==sizeof(Event<>)(==sizeof(void*) ), but the effort involved in revising containing Ctrl (ScrollBar, EditWithSpin, DropList, etc)'s Paint,LeftDown,LeftRepeat, etc, will be quite similar to hardcoding each of the Ctrl's method that we need to change to allow the savings to take place.




This would be too long. What we need is class Buttons like this:

class Buttons : Ctrl {
   virtual int  GetButtonCount() = 0;
   virtual Rect GetButtonRectint i) = 0;
   virtual int  ButtonMouseDown(Point p);
   virtual int  ButtonMouseUp(Point p);
   virtual int  ButtonMouseMove(Point p);
}

Re: Know what you're using. Size of some common types. [message #57988 is a reply to message #57987] Mon, 10 January 2022 02:00 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
Great. For WithSpin<> which in turn contains SpinButtons, this can roughly reduce the object size by 2*sizeof(Button) - sizeof(Ctrl). That's a great achievement with minimal impact on existing code. It will just work.(Well, SpinButtons exposed Button inc, dec; but it should not be referenced much except in the library implementation anyways).

And it's a generic solution. No matter how many buttons it fakes, it will take up room of only sizeof(Ctrl).

For WithSpin in particular, another route I was considering (I am not versed with Upp enough to know whether it will work) is to start from EditField. Basically add 2 bitfield bool
class EditField:....
{
....
public:
      void Paint(Draw& d)override{
           PaintSpinButtons();
           DoOriginalEditFieldPaintOnReducedSize();
      }
      void LeftDown(Point p, dword f)override{
           if(p not in SpinPart)
                Parent::LeftDown(p,f);
           else if(p in UpperPart of Spin)
                WhenSpin(false);
           else// (p in LowerPart of Spin)
                WhenSpin(true);
      }
      void LeftRepeat(Point p, dword f)override{
           LeftDown(p,f);
      }
      Image CursorImage(Point p, dword)override{
          // Image according to part of the Ctrl
      }
      //... maybe more to be override'd or rewrite to take care of Fake SpinButton part.

      Event<bool> WhenSpin;
private:
      bool with_spin : 1;
      bool spin_visible : 1;

      Size GetReducedSize(){
            Size sz=GetSize(); 
            if(with_spin && spin_visible)
                 reduce_size_to_leave_room_for_spin_buttons(sz);
     }
}


Then in actual types(EditIntWithSpin, EditInt64WithSpin, etc) that needs SpinButtons, we just turn the flags on in respective constructors, and connect to WhenSpin event.


I am not sure if we claim part of EditField as Frame without actully AddFrame, etc, will work as wished.

If you figure this route is worth considering, I can do a preliminary implementation. Otherwise (if you prefer the more normal Buttons route), I will wait and see. Razz

[Updated on: Mon, 10 January 2022 02:29]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57991 is a reply to message #57988] Mon, 10 January 2022 21:43 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
Buttons established a concept. If implemented with due care, it will arrive at same Ctrl size (eg, ScrollBar, SpinButtons) as when hardcoded (like the way I do ScrollBar). That being said, Buttons interface are not expected to save much work (than hard coded way), if any. Personally I will do without: I don't see the benefit here, except the visual clue that they are doing similar things.

I have performed a simple test on adding SpinButtons to EditField without resorting to a CtrlFrame, and it works like a charm. I know this is not conceptually right, but it will work in practice and save memory of a little over sizeof(Ctrl) for each EditWithSpin object than the Buttons way mirek is considering. The only functionality it lose is when there are multiple frames, you cannot choose to put the SpinButtons frame on anywhere except innermost, because it's not a real CtrlFrame.

The Test is very simple, start a CtrlLib project with a Main Window with a EditField and a EditInt64WithSpin. Now we start to play around with CtrlLib.

In <CtrlLib/EditCtrl.h, add a new virtual function to class EditField
class EditField : public Ctrl, private TextArrayOps {
public:
	virtual void  Layout();
	virtual void  Paint(Draw& draw);
	virtual void  LeftDown(Point p, dword keyflags);
        ... omitted
	virtual void   State(int);
	

        // newly introduced
	virtual Size   GetReducedSize()const{
              // EditField::GetReducedSize() should just return GetSize();
              // it's the WithSpin derived class that should override this
              // function to reserve room for SpinButtons.
              //
              // here we reduce it as if allocating space for SpinButtons
              Size sz = GetSize();
              sz.cx -= 30;
              if(sz.cx < 0)
                   sz.cx=0;
              return sz;
         }[/b]
...


In <CtrlLib/EditField.cpp>, search all occurence of "GetSize()", if it's not "GetSize().cy", and is not "GetParent()->GetSize()", repace it with "GetReducedSize()". Run the test program, notice the room for SpinButton has been allocated, and play with some input in the EditField, see it scroll horizontally properly when the text gets really long. Now we can be certain this route is feasible. And it will come out with more compact EditXXWithSpins than to retain Buttons in a CtrlFrame. I would say the amount of coding involved are quite similar in both ways.

I will otherwise leave EditField (except probably add a spin_visible bitfield member intended for EditXXwithSpin). Then override Paint, relevant mouse event virtual function in WithSpin<> template class. It's quite similar to what I did with ScrollBar. No impact will be felt by libary users except smaller EditXXWithSpin objects---class hierarchy and interfaces remain unchanged.

[Updated on: Mon, 10 January 2022 21:54]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57992 is a reply to message #57991] Tue, 11 January 2022 02:29 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
WithSpin<> has method named OnSides() which allows the SpinButtons be splitted on both side of the EditField. Not putting SpinButtons in a CtrlFrame will require a lot more work to modify EditField::Paint() etc. Housing it in a CtrlFrame is cleaner and safer.
Re: Know what you're using. Size of some common types. [message #57993 is a reply to message #57991] Tue, 11 January 2022 13:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Lance wrote on Mon, 10 January 2022 21:43
That being said, Buttons interface are not expected to save much work (than hard coded way), if any.


You wanna bet? Smile

Mirek
Re: Know what you're using. Size of some common types. [message #57994 is a reply to message #57993] Tue, 11 January 2022 15:19 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
I see. You will provide underlying facilities to support the Buttons interface so that by implementing the interface, underlying CtrlLib or CtrlCore facilities will draw it correctly and deliver mouse event etc as if each button is a actual Ctrl.


For WithSpin<>.OnSides, the painting can be taken care of by Draw.Offset. Not sure if there will be more complications.

[Updated on: Tue, 11 January 2022 17:47]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57995 is a reply to message #57994] Tue, 11 January 2022 17:40 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
This idea might worth further generalization:

For example, we have an ArrayCtrl who is housing thousands of child Ctrl: edits, buttons, etc. Technicallu, each child don't need to worry about its location and size which will be set to whatever the ArrayCtrl decides. I am sure there will be a lot more states a resident child doesn't need to worry about, similar to the Buttons case, but more generic: each child is determined by a row and a column, unlike in Buttons case we only need an index to identify a fake Ctrl. As these interface may be required by both ArrayCtrl and GridCtrl, ideally the support can be built into Ctrl base class. And Edits, Button, etc need to provide a fake version (not derived from Ctrl, while the real version ,like
what they are, is just fake controls contained in Ctrl which they also derive from.

[Updated on: Tue, 11 January 2022 17:44]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57996 is a reply to message #57995] Tue, 11 January 2022 22:07 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
If ArrayCtrl limits children to Fake Ctrls only, SyncLineCtrls etc will be dispensible.

Back to Buttons, some chain of thoughts. Instead of inheriting from Ctrl, it should be leave as an interface (no data members); concrete Ctrls will decide whether to inherit from Ctrl, ArrayCtrl, EditField or other Ctrl derivatives and implementing the interface to use the Ctrl's Paint & other virtual functions to fake out Buttons.

This will add a cost of sizeof(void *) (pointer to interface vtbl) to each object of Classes that implement the interface. Why not add the interface (a set of virtual functions) to Ctrl directly to save this vtble pointer?
class Ctrl : public ...
{
public:
     virtual void Paint(Draw& w)
     {
            for(int i = 0; i < GetFakeCtrlsCount(); ++i)
            {
                 Rect r=GetFakeCtrlsRect(i);
                 w.Clipoff(r);
                 PaintFakeCtrls(w, i);
                 w.End();
            }
     }
     virtual void LeftDown(Point p, dword flag)
     {
            for(int i = 0; i < GetFakeCtrlsCount(); ++i)
            {
                 Rect r=GetFakeCtrlsRect(i);
                 if( MouseInRect(r) )
                 {
                      p.x -= r.left; p.y -= r.top;
                      FakeCtrlsLeftDown(p, flag, i);
                      break;
                 }
            }
     }
     ...
      // added to support fake Ctrls
      virtual int GetFakeCtrlsCount()const{ return 0; }
      virtual void PaintFakeCtrls(Draw& w, int index){}
      virtual void FakeCtrlsLeftDown(Point p, dword flag, int index){}
      ... and some more virtual function of Ctrl with an extra parameter index.
};

This way we don't explicitly limit the type of fake Ctrls (Not even by a non-restrictive but suggestive name "Buttons"). It's totally up to each derivative that actually implements the interface to decide what Ctrls it wants to fake.

------------
PS: instead of repeatedly calling multiple virtual functions to Paint each fake Ctrl, it make sense to instead
class Ctrl: ...
{
public:
     ...
       virtual void PaintFakeCtrls(Draw& w);
      ...

Then the PaintFakeCtrls() will be quite like ScollBar::Paint(). I don't know, let's see how you do it clearly and efficiently.

[Updated on: Tue, 11 January 2022 22:46]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #57997 is a reply to message #57996] Tue, 11 January 2022 22:25 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
The cost is the size of the vtable of Ctrl and each of its derivatives almost doubles. With the number of classes in the hierarchy, this could be quite big to ignore. Then we get something like suggested by you Laughing
class CtrlWithFakeCtrls : public Ctrl
{
...
}


Only Ctrls derived from the class are able to make use of the facility. If any existing Ctrl is believed to be able to benefit from it, we just change its base class.

Now I get your point. It's nice.

[Updated on: Tue, 11 January 2022 22:32]

Report message to a moderator

Re: Know what you're using. Size of some common types. [message #58374 is a reply to message #57997] Wed, 11 May 2022 09:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
So here I am after one month of optimizing:

Current U++:

* C:\upp\out\benchmarks\CLANGx64.Gui\sizeof_gui.exe 29.04.2022 17:35:45, user: cxl

sizeof(Image) = 8
sizeof(RichText) = 248
sizeof(Ctrl::LogPos) = 8
sizeof(LabelBase) = 136
=============
sizeof(Ctrl) = 152
sizeof(ScrollBar) = 1136
sizeof(HeaderCtrl) = 1456
sizeof(Button) = 224
sizeof(Switch) = 224
sizeof(Label) = 296
sizeof(EditField) = 440
sizeof(EditString) = 456
sizeof(EditInt) = 472
sizeof(SpinButtons) = 472
sizeof(EditIntSpin) = 952
sizeof(DisplayPopup) = 256
sizeof(PopUpTable) = 3824
sizeof(WithDropChoice<EditString>) = 4920
sizeof(DropList) = 4488
sizeof(ArrayCtrl) = 3784
sizeof(TreeCtrl) = 3656
sizeof(TreeCtrl::Node) = 80
sizeof(FileSel) = 26056
sizeof(RichTextView) = 1632
sizeof(ColumnList) = 1752
sizeof(RichEdit) = 69464



gui_sizeof branch:

* C:\upp\out\gui_sizeof_benchmarks\CLANGx64.Blitz.Gui\sizeof_gui.exe 11.05.2022 09:39:05, user: cxl

sizeof(Image) = 8
sizeof(RichText) = 248
sizeof(Ctrl::LogPos) = 8
sizeof(LabelBase) = 64
=============
sizeof(Ctrl) = 104
sizeof(ScrollBar) = 192
sizeof(HeaderCtrl) = 464
sizeof(Button) = 176
sizeof(Switch) = 176
sizeof(Label) = 176
sizeof(EditField) = 320
sizeof(EditString) = 336
sizeof(EditInt) = 352
sizeof(SpinButtons) = 376
sizeof(EditIntSpin) = 384
sizeof(DisplayPopup) = 16
sizeof(PopUpTable) = 1552
sizeof(DropList) = 440
sizeof(WithDropChoice<EditString>) = 760
sizeof(ArrayCtrl) = 1512
sizeof(TreeCtrl) = 1288
sizeof(TreeCtrl::Node) = 80
sizeof(FileSel) = 8536
sizeof(RichTextView) = 640
sizeof(ColumnList) = 520
sizeof(RichEdit) = 22728
Re: Know what you're using. Size of some common types. [message #58375 is a reply to message #58374] Thu, 12 May 2022 08:26 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
FYI.
I've attached three tab-separated tables having a header below:
Type, Name, TypeIndex, Nested, Size, Padding, Padding/Size

This info is for TheIDE, Release, Windows. It is retrieved from debug info (this can be done in Windows and Unix)

Sorted by Size:
struct	Upp::MemoryProfile	11203	0	278616	20	0.0000717834
struct	Upp::MemoryProfile	99836	0	278616	20	0.0000717834
struct	Ide	10	0	232488	108	0.0004645401
struct	Ide	43920	0	232488	108	0.0004645401
class	BuildMethods	71641	0	174176	0	0
class	BuildMethods	825	0	174176	0	0
struct	ZSTD_DCtx_s	118100	0	160312	18	0.0001122811
struct	ZSTD_DCtx_s	1331	0	160312	18	0.0001122811
struct	Upp::HeaderFooterDlg	5573	0	141680	0	0
class	Upp::PatchDiff	102483	0	135664	4	0.0000294846
class	Upp::PatchDiff	6438	0	135664	4	0.0000294846
class	Upp::PatchDiff	6440	0	135664	4	0.0000294846
class	Upp::PatchDiff	65233	0	135664	4	0.0000294846
class	Upp::GIFRaster::Data	123850	1	133624	14	0.0001047716
class	Upp::GIFRaster::Data	2175	1	133624	14	0.0001047716
class	Data	123927	1	133624	14	0.0001047716
class	Data	123927	1	133624	14	0.0001047716
class	Upp::GIFEncoder::Data	6934	1	131432	0	0
class	Data	124015	1	131432	0	0
class	Upp::GIFEncoder::Data	124084	1	131432	0	0
struct	Upp::sPalMaker	128970	0	131076	0	0
struct	Upp::sPalMaker	109	0	131076	0	0
struct	CLzmaEnc	1268	0	123272	8	0.0000648971
struct	CLzmaEnc	117784	0	123272	8	0.0000648971
struct	Pool	87626	1	114888	11	0.0000957454
struct	Pool	87626	1	114888	11	0.0000957454
struct	Upp::CoWork::Pool	11093	1	114888	11	0.0000957454
class	DefaultBuilderSetup	463	0	109368	0	0
class	Upp::StyleManager	5023	0	104200	4	0.0000383877
class	Upp::StyleManager	119901	0	104200	4	0.0000383877
class	TopicEditor	2965	0	85088	7	0.0000822678
class	TopicEditor	74943	0	85088	7	0.0000822678
class	Upp::DirDiffDlg	102374	0	81664	0	0
class	Upp::DirDiffDlg	548	0	81664	0	0
class	Upp::DirDiffDlg	45948	0	81664	0	0
class	Upp::DirDiffDlg	546	0	81664	0	0
struct	Upp::ParaFormatDlg	9045	0	80640	0	0
class	Upp::ParaFormatting	1638	0	79848	14	0.0001753331
class	Upp::ParaFormatting	119816	0	79848	14	0.0001753331
struct	QtfDlgEditor	6998	0	70416	0	0
struct	IdeQtfDes	2039	0	70096	0	0
struct	IdeQtfDes	103543	0	70096	0	0
class	Upp::RichEditWithToolBar	6608	0	70072	7	0.0000998972
class	Upp::RichEditWithToolBar	6606	0	70072	7	0.0000998972
struct	Upp::RichEditHdrFtr	11338	0	70064	0	0
class	Upp::RichEdit	7027	0	69464	41	0.0005902338
class	Upp::RichEdit	7025	0	69464	41	0.0005902338
class	Upp::RichEdit	7029	0	69464	41	0.0005902338
class	Upp::RichEdit	120597	0	69464	41	0.0005902338
class	Upp::RichEdit	68731	0	69464	41	0.0005902338
struct	Upp::WordDistanceTester	109746	0	67076	0	0
struct	Upp::WordDistanceTester	6526	0	67076	0	0
struct	DState	7923	0	64144	9	0.0001403093
struct	FormatDlg	10024	0	64136	0	0
struct	OutMode	2169	0	62928	0	0
struct	WithSetupFontLayout<Upp::ParentCtrl>	1817	0	58800	160	0.0027210884
struct	EState	7925	0	55768	8	0.0001434514
class	Gdb	81257	0	51688	28	0.0005417118
class	Gdb	35	0	51688	28	0.0005417118
struct	Pdb	73	0	48864	42	0.0008595285
struct	Pdb	82340	0	48864	42	0.0008595285
struct	AssistEditor	2647	0	48184	29	0.0006018595

Sorted by Padding:
class	Upp::CodeEditor	92617	0	19104	3468	0.1815326633
class	Upp::CodeEditor	973	0	19104	3468	0.1815326633
class	Upp::CodeEditor	975	0	19104	3468	0.1815326633
class	Upp::CodeEditor	39471	0	19104	3468	0.1815326633
class	Upp::ImagePainter	8169	0	1128	1072	0.9503546099
struct	Upp::WithPaletteLayout<Upp::TopWindow>	8787	0	9648	344	0.035655058
struct	WithTemplateListLayout<Upp::TopWindow>	1602	0	4576	344	0.0751748252
struct	WithSimpleListLayout<Upp::TopWindow>	10165	0	4576	344	0.0751748252
struct	Upp::WithMacroManagerLayout<Upp::TopWindow>	3045	0	1704	344	0.2018779343
struct	WithUrepoConsoleLayout<Upp::TopWindow>	7591	0	4576	344	0.0751748252
struct	WithExportTrLayout<Upp::TopWindow>	4231	0	15768	344	0.0218163369
struct	Upp::WithPaletteSelectorLayout<Upp::TopWindow>	10028	0	944	344	0.3644067797
struct	WithInsertAsLayout<Upp::TopWindow>	8805	0	1312	344	0.262195122
struct	WithCustomLayout<Upp::TopWindow>	9241	0	5392	344	0.0637982196
struct	WithMoveTopicLayout<Upp::TopWindow>	3205	0	20552	344	0.0167380304
struct	WithSetupWebSearchEngineLayout<Upp::TopWindow>	6467	0	2592	344	0.1327160494
struct	Upp::WithImageSizeLayout<Upp::TopWindow>	11622	0	3288	344	0.104622871
struct	WithRenamePackageLayout<Upp::TopWindow>	7263	0	1840	344	0.1869565217
struct	WithConfLayout<Upp::TopWindow>	3688	0	5792	344	0.0593922652
struct	Upp::WithHexGotoLayout<Upp::TopWindow>	6162	0	6008	344	0.0572569907
struct	WithSaveTemplateLayout<Upp::TopWindow>	6802	0	15472	344	0.0222337125
struct	Upp::WithSimpleSelectLayout<Upp::TopWindow>	7940	0	4576	344	0.0751748252
struct	WithCredentialLayout<Upp::TopWindow>	2412	0	8040	344	0.0427860697
struct	Upp::WithImageLayout<Upp::TopWindow>	7100	0	5432	344	0.0633284242
struct	Upp::WithFileSelectorLayout<Upp::TopWindow>	10310	0	18168	344	0.0189343901
struct	WithNewPackageLayout<Upp::TopWindow>	9953	0	11152	344	0.0308464849
struct	Upp::WithEditIntLayout<Upp::TopWindow>	4129	0	1560	344	0.2205128205
struct	WithLangLayout<Upp::TopWindow>	9111	0	16384	344	0.0209960938
struct	WithBaseSetupLayout<Upp::TopWindow>	9523	0	4472	344	0.0769230769
struct	Upp::WithCellPropertiesLayout<Upp::TopWindow>	3301	0	16312	344	0.021088769
struct	WithGotoMemoryLayout<Upp::TopWindow>	10812	0	6776	344	0.0507674144
struct	WithQuickwatchLayout<Upp::TopWindow>	1587	0	9144	344	0.0376202975
struct	WithMatrixLayout<Upp::TopWindow>	9943	0	5784	344	0.0594744122
struct	WithAddLangLayout<Upp::TopWindow>	2193	0	9936	344	0.0346215781
struct	WithTppLayout<Upp::TopWindow>	11550	0	5624	344	0.0611664296
struct	WithFindInFilesLayout<Upp::TopWindow>	568	0	33064	344	0.0104040648
struct	WithCharsetLayout<Upp::TopWindow>	7572	0	5576	344	0.0616929699
struct	Upp::WithRescaleLayout<Upp::TopWindow>	1186	0	7048	344	0.0488081725
struct	Upp::WithUnitLayout<Upp::TopWindow>	8941	0	7784	344	0.0441932169
struct	WithPasskeyLayout<Upp::TopWindow>	2155	0	2304	344	0.1493055556
struct	Upp::WithSplitCellLayout<Upp::TopWindow>	9882	0	3288	344	0.104622871
struct	WithMoveCopyPackageLayout<Upp::TopWindow>	5037	0	6984	344	0.049255441
struct	WithPrintLayout<Upp::TopWindow>	8193	0	2552	344	0.1347962382
struct	WithGetPasskeyLayout<Upp::TopWindow>	7321	0	1552	344	0.2216494845
struct	WithAutoSetupLayout<Upp::TopWindow>	4127	0	1768	344	0.1945701357
struct	Upp::WithRichFindReplaceLayout<Upp::TopWindow>	8541	0	11912	344	0.0288784419
struct	WithNestEditorLayout<Upp::TopWindow>	10780	0	5696	344	0.0603932584
struct	WithRunLayout<Upp::TopWindow>	6662	0	15368	344	0.0223841749
struct	WithLicenseLayout<Upp::TopWindow>	8869	0	3016	344	0.1140583554
struct	WithNewTopicLayout<Upp::TopWindow>	4786	0	15472	344	0.0222337125
struct	WithVisGenLayout<Upp::TopWindow>	6277	0	26104	344	0.013178057
struct	WithSelectPackageLayout<Upp::TopWindow>	10725	0	11288	344	0.0304748405
struct	WithAbbreviationsLayout<Upp::TopWindow>	6285	0	24648	344	0.0139565076
struct	Upp::WithObjectSizeLayout<Upp::TopWindow>	206	0	7240	344	0.0475138122
struct	Upp::WithFileSelectorLayout<Upp::TopWindow>	10308	0	18168	344	0.0189343901
struct	WithSetupGITLayout<Upp::TopWindow>	3425	0	3280	344	0.1048780488
struct	Upp::WithIDEFindReplaceLayout<Upp::TopWindow>	10873	0	14192	344	0.0242390079

Sorted by Padding/Size:
class	Upp::ImagePainter	8169	0	1128	1072	0.9503546099
struct	_DEBUG_EVENT	3331	0	176	160	0.9090909091
struct	COFF_IMAGE_SYMBOL	3051	0	26	16	0.6153846154
struct	COFF_IMAGE_SYMBOL	139682	0	26	16	0.6153846154
struct	jpeg_error_mgr	260	0	168	88	0.5238095238
class	Upp::CallbackN<int,bool &>	1397	0	16	8	0.5
class	Upp::CallbackN<int,int>	56432	0	16	8	0.5
class	Upp::CallbackN<Upp::Stream &>	9252	0	16	8	0.5
class	Upp::CallbackN<int,int>	5209	0	16	8	0.5
class	Upp::CallbackN<const int &>	119721	0	16	8	0.5
class	Upp::CallbackN<const Upp::String &,Upp::Vector<Upp::LineEdit::Highlight> &,const Upp::WString &>	5426	0	16	8	0.5
class	Upp::CallbackN<bool,const Upp::String &,Upp::Image &>	75509	0	16	8	0.5
struct	ValueType	55349	1	16	8	0.5
class	Upp::CallbackN<const Upp::String &,Upp::Vector<Upp::LineEdit::Highlight> &,const Upp::WString &>	66671	0	16	8	0.5
class	Upp::GateN<>	10086	0	16	8	0.5
class	Upp::GateN<int,int>	2708	0	16	8	0.5
class	Upp::GateN<Upp::CodeEditor::MouseTip &>	66796	0	16	8	0.5
class	Upp::CallbackN<Upp::Bar &>	1485	0	16	8	0.5
class	Upp::CallbackN<Upp::String &>	66756	0	16	8	0.5
class	Upp::CallbackN<Upp::String>	64253	0	16	8	0.5
struct	ValueType	55349	1	16	8	0.5
class	Upp::CallbackN<bool,const Upp::String &,Upp::Image &>	1154	0	16	8	0.5
class	Upp::CallbackN<Upp::Time &>	95128	0	16	8	0.5
class	Upp::CallbackN<Upp::String &,Upp::WString &>	8703	0	16	8	0.5
class	Upp::CallbackN<int,Upp::PasteClip &>	37998	0	16	8	0.5
class	Upp::GateN<Upp::CodeEditor::MouseTip &>	2995	0	16	8	0.5
struct	Upp::RichTxt::Part	55362	1	16	8	0.5
struct	value_type	55350	1	16	8	0.5
class	Upp::GateN<>	113352	0	16	8	0.5
class	Upp::CallbackN<const Upp::String &,const Upp::String &>	99218	0	16	8	0.5
class	Upp::CallbackN<Upp::Point_<int> >	37972	0	16	8	0.5
class	Upp::CallbackN<long long>	10110	0	16	8	0.5
class	Upp::GateN<int,int>	94204	0	16	8	0.5
class	Upp::CallbackN<Upp::Bar &>	24631	0	16	8	0.5
class	Upp::CallbackN<int>	5035	0	16	8	0.5
class	Upp::CallbackN<long long>	66825	0	16	8	0.5
class	Upp::CallbackN<int,Upp::PasteClip &>	4225	0	16	8	0.5
class	Upp::CallbackN<int,const Upp::String &>	91852	0	16	8	0.5
class	Upp::CallbackN<int,const Upp::String &>	2099	0	16	8	0.5
struct	Upp::RichTxt::Part	2071	1	16	8	0.5
class	Upp::CallbackN<Upp::One<Upp::Ctrl> &>	26383	0	16	8	0.5
class	Upp::CallbackN<Upp::PasteClip &>	8017	0	16	8	0.5
struct	value_type	138946	1	16	8	0.5
class	Upp::CallbackN<Upp::EscEscape &>	250	0	16	8	0.5
class	Upp::CallbackN<Upp::Point_<int> >	1598	0	16	8	0.5
struct	Part	51523	1	16	8	0.5
class	Upp::CallbackN<const char *>	472	0	16	8	0.5
class	Upp::CallbackN<const char *>	58355	0	16	8	0.5
class	Upp::CallbackN<Upp::EscEscape &>	66862	0	16	8	0.5
class	Upp::CallbackN<int>	52370	0	16	8	0.5
class	Upp::GateN<long long,long long>	3299	0	16	8	0.5
class	Upp::GateN<long long,long long>	64649	0	16	8	0.5
class	Upp::CallbackN<const Upp::String &>	66709	0	16	8	0.5
class	Upp::CallbackN<const int &>	5404	0	16	8	0.5
class	Upp::CallbackN<Upp::Stream &>	31135	0	16	8	0.5
class	Upp::CallbackN<Upp::Time &>	6708	0	16	8	0.5
struct	value_type	55350	1	16	8	0.5
struct	asn1_type_st	478	0	16	8	0.5
class	Upp::CallbackN<Upp::String &>	10703	0	16	8	0.5
class	Upp::CallbackN<>	24613	0	16	8	0.5
class	Upp::CallbackN<Upp::One<Upp::EditorSyntax> &>	92123	0	16	8	0.5
struct	value_type	138946	1	16	8	0.5
class	Upp::CallbackN<>	7716	0	16	8	0.5
class	Upp::CallbackN<Upp::One<Upp::EditorSyntax> &>	11314	0	16	8	0.5
class	Upp::CallbackN<int,bool &>	61655	0	16	8	0.5
class	Upp::CallbackN<Upp::PasteClip &>	86672	0	16	8	0.5
class	Upp::CallbackN<const Upp::String &,const Upp::String &>	5211	0	16	8	0.5
class	Upp::CallbackN<const void *,int>	100988	0	16	8	0.5
struct	Part	51523	1	16	8	0.5
class	Upp::CallbackN<Upp::String>	3828	0	16	8	0.5
class	Upp::CallbackN<const Upp::String &>	11143	0	16	8	0.5
class	Upp::CallbackN<Upp::One<Upp::Ctrl> &>	2277	0	16	8	0.5
class	Upp::CallbackN<Upp::String &,Upp::WString &>	88967	0	16	8	0.5
class	Upp::CallbackN<const void *,int>	4958	0	16	8	0.5
struct	AppPreview::Line	2523	1	32	15	0.46875
struct	Line	31709	1	32	15	0.46875
struct	ValueType	32269	1	32	15	0.46875
struct	AppPreview::Line	32282	1	32	15	0.46875
struct	ValueType	32269	1	32	15	0.46875
struct	value_type	32270	1	32	15	0.46875
struct	value_type	32270	1	32	15	0.46875
struct	Upp::Iml::IImage	17989	1	16	7	0.4375
struct	ValueType	18704	1	16	7	0.4375
struct	Upp::sThreadParam	5869	0	16	7	0.4375
struct	Upp::Iml::IImage	11268	1	16	7	0.4375
struct	ValueType	18589	1	16	7	0.4375
class	Upp::WaitCursor	5752	0	16	7	0.4375
struct	value_type	18705	1	16	7	0.4375
struct	Upp::H_l_	9555	0	16	7	0.4375
struct	value_type	17978	1	16	7	0.4375
class	Pdb::CopyMenu::<lambda24>	86333	0	16	7	0.4375
class	Pdb::CopyMenu::<lambda25>	86334	0	16	7	0.4375
struct	value_type	17978	1	16	7	0.4375
struct	Upp::TupleN<2,unsigned char,const char *>	606	0	16	7	0.4375
struct	Upp::TupleN<2,unsigned char,const char *>	109882	0	16	7	0.4375
struct	IImage	17819	1	16	7	0.4375
struct	ValueType	18704	1	16	7	0.4375
class	Pdb::CopyMenu::<lambda24>	86117	0	16	7	0.4375
struct	ValueType	18589	1	16	7	0.4375
struct	IImage	17819	1	16	7	0.4375
class	Upp::DirDiffDlg::DirDiffDlg::<lambda0>::operator()::<lambda1>	102429	0	16	7	0.4375
struct	value_type	18705	1	16	7	0.4375
class	Upp::DirDiffDlg::DirDiffDlg::<lambda0>::operator()::<lambda1>	102522	0	16	7	0.4375
class	Pdb::CopyMenu::<lambda25>	86125	0	16	7	0.4375



Regards,
Novo
Re: Know what you're using. Size of some common types. [message #58381 is a reply to message #58375] Sat, 14 May 2022 21:30 Go to previous message
Lance is currently offline  Lance
Messages: 526
Registered: March 2007
Contributor
Great job! Thank you, Mirek!
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: Thu Mar 28 16:16:55 CET 2024

Total time taken to generate the page: 0.02084 seconds