Question: I'm currently working on a WPF application which will run on Windows 8.1 tablet and I don't find any posts about the following issue :

My application needs to be full screen, so, I set for my views :

```
 WindowState="Maximized"
 WindowStyle="ToolWindow"

```

All right - my application will be displayed in full screen mode:
![](https://i.stack.imgur.com/lFYpB.png)

But, if I rotate the tablet a space is allocated and the application is not in full screen. 

![enter image description here](https://i.stack.imgur.com/y0oe7.png)

I don't want this scenario to happen, the application should stay always in full screen.

I tried to listen SystemEvents.DisplaySettingsChanged event and manually set full screen:

```
SystemEvents.DisplaySettingsChanged += Current_SizeChanged;

private void Current_SizeChanged(object sender, EventArgs eventArgs)
{
    this.WindowStyle = WindowStyle.None;
    this.ResizeMode = ResizeMode.NoResize;
    this.WindowState = WindowState.Maximized;    
    this.UpdateLayout();
}

```

As you can see, i tried even to update layout, but still, not working!
What is strange, is the fact that if you start the application in any position but not in the normal one, it will work. For ex: if the application is started in portrait mode, rotation will not change the dimensions of the window, but if you run the application starting from landscape mode... the bug appears.

You can debug this issue using Ctrl + Alt + Arrows. 

Any suggestions?

**Edit:** It seems that the problem is caused by keyboard. The reserved zone is for keyboard, but i don't find a way to resize to full screen. Actual width, Width and Desired Width are all the same... 

**Edit2:** This bug can be reproduced only on Windows 8.1

Answer: 
> 
> My suspicion is that it is advantageous to use call-by-reference as soon as the primitive type's size in bytes exceeds the size of the address value. Even if the difference is small, I'd like to take the advantage because I call some of these functions quite often.
> 
> 
> 

Performance tweaking based on hunches works about 0% of the time in C++ (that's is a gut feeling I have about statistics, it works usually...)

It is correct that the `const T&` will be smaller than the `T` if `sizeof(T) > sizeof(ptr)`, so usually 32-bits, or 64, depending on the system..

Now ask yourself :

1) How many built-in types are bigger than 64 bits ?

2) Is not copying 32-bits worth making the code less clear ? If your function becomes significantly faster because you didn't copy a 32bit value to it, maybe it doesn't do much ?

3) Are you really that clever ? (spoiler alert : no.) See this great answer for the reason why it is almost always a bad idea :
<https://stackoverflow.com/a/4705871/1098041>

Ultimately just pass by value. If after (thorough) profiling you identify that some function is a bottleneck, and all of the other optimizations that you tried weren't enough (and you should try most of them before this), pass-by-const-reference.

Then See that it doesn't change anything. roll-over and cry.
I addition to the other answers I would like to note that when you pass a reference and use (aka dereference) that a lot in your function, it could be slower than making a copy.

This is because local variables to a function (usually) get loaded into the cache together, but when one of them is a pointer/reference and the function uses that, it could result in a cache miss. Meaning it needs to go to the (slower) main memory to get the pointed to variable, which could be slower than making the copy which is loaded in cache together with the function.

So even for 'small objects' it could be potentially faster to just pass by value.

(I read this in the very good book: [Computer Systems: a programmers perspective](http://csapp.cs.cmu.edu/))

Some more interesting discussion on the whole cache hit/miss topic: [How does one write code that best utilizes the CPU cache to improve performance?](https://stackoverflow.com/questions/763262/how-does-one-write-code-that-best-utilizes-the-cpu-cache-to-improve-performance)