On Sat, Aug 30, 2014, at 10:47 AM, Liam White wrote:

While browsing through header files in experimental I found these sort of things: sp-object.h unsigned int cloned : 1;

unsigned int set : 1; unsigned int value : 1; sp-namedview.h unsigned int editable : 1; unsigned int showguides : 1; unsigned int showborder : 1; unsigned int showpageshadow : 1;

These look very much like a holdover from C which did not have a boolean type like C does. Is there any viable reason for not simply converting these to boolean?

There are other, similar things that I saw as well (sp-namedview.h):

unsigned int borderlayer : 2;

and I believe this variable is meant to hold an enum type. Should it just be changed to the type of the enum with no alignment or is there a reason to not do that?

Those also are a optimization for space. There is an expectation that the compiler will pack together all those specified to use a single bit into one int.

Of course that then gives a penalty for performance. For the namedview I would say that optimizing for space is not really needed since there will be relatively few of those. The question for sp-object would be to measure how many instances we encounter in various situations and documents and what kind of measured impact on memory use we might see. additionally if we can get any measurable performance difference detected that would be quite interesting.

Changing from int-plus-#defines to a real enum for things like borderlayer is probably a no-brainer since that goes to code safety and greatly reduces the chance for certain bugs. The only factor for concern would be if a member was on a struct/class that we get a significant number of instances of.

-- Jon A. Cruz jon@...18...

On Sat, Aug 30, 2014, at 12:09 PM, Nathan Hurst wrote:

On Sat, Aug 30, 2014 at 11:07:02AM -0700, Jon A. Cruz wrote:

...

Those also are a optimization for space. There is an expectation that the compiler will pack together all those specified to use a single bit into one int.

Of course that then gives a penalty for performance.

These days space optimisation is performance optimisation - if everything is in the cache things go much faster. Setting and clearing bits takes no more time than setting and clearing words in practice.

(I agree with everything else you said)

Except... for larger word architectures, fetching and bit twiddling can take longer. Depends on the number, packing, etc.

Since I've seen this take performance both ways, I'd be interested in how it works on current CPUs in 32-bit and 64-bit modes for our use cases. I've actually measured performance degradation in the past when using bitfields, but I understand it is a context sensitive issue. I'd also be a bit surprised if our structs changing from bitfields to booleans would grow large enough to push that out of the cache.

However... if performance is a non-issue, there are still some other reasons to favor booleans over bitfields. This includes avoiding use of uninitialized memory that can cause noise and distortion with tools like Valgrind.