Does the sketch size reported after compile include PROGMEM variables?

Basically, as per the subject line, when I compile a sketch which uses PROGMEM, for example to store large arrays of bytes, does the reported program storage space include the amount used by 'PROGMEM' variables?

For example:

const uint8_t PROGMEM Array_A[] = {
    0x16, 0x00, 0x01, 0x64,
    0x17, 0x00, 0x02, 0x64,
    0x18, 0x00, 0x03, 0x64,
    0x19, 0x00, 0x05, 0x64,
    0x1A, 0x00, 0x07, 0x64,
    0x2A, 0x00, 0x10, 0x64,
    0x00, 0x00, 0x10, 0x00,
etc.

Sketch uses 58392 bytes (22%) of program storage space. Maximum is 253952 bytes.
Global variables use 2528 bytes (30%) of dynamic memory, leaving 5664 bytes for local variables. Maximum is 8192 bytes.

Does the 58392 include the memory used by Array_A?

Comment it out, recompile, and see what changes.

Yes.

It should, provided the array is actually needed. The compiler may eliminate it completely if it can be determined at compile time that the array is not needed, or only a single element is needed (in which case the array is eliminated, and the single necessary value is hard-coded into the code).

I think that was what was happening as sometimes the size reported did not change when I merely added the array but didn't use it. So, it looks like you are correct, and the compiler optimises it out. I then tried setting one or two elements in the array to different values and that did seem to change the program size. One learns something new every day LOL

Thanks to everyone who has suggested things to try.

The array is always stored in flash no matter with or without PROGMEM. The difference is only the RAM usage. Without PROGMEM the array content is copied to RAM when the sketch starts and within the program the values are read from RAM. With PROGMEM the array content is not copied to RAM and is read from flash within the program ( what needs more code and time ).
Therefore the flash usage always includes your array content - with or without PROGMEM. It only maybe optimized away completely by the compiler if not used ( as already stated ).

Thanks @MicroBahner . One more question, if I declare the array as const uint8_t without the PROGMEM, since the compiler 'knows' the array contents will never be changed as it is declared constant, how does the compiler handle that: does it keep it in FLASH and not copy to RAM? My reason for asking is that in my actual sketch I have several (10 or 12) such large arrays (about 1500 bytes each) and even when I did not have the PROGMEM modifier, my sketch still seemed to work which surprised me since the ATmega2560 I am using only has 8k SRAM! Of course that may be because I hadn't actually used the arrays yet :thinking:

I'm just trying to better understand how all this compiler 'magic' works!

The problem with PROGMEM ( why it is needed at all ) is the architecture of the AVR processors. These processors have completely different HW to access flash or RAM. The usually used processor commands to access RAM Data don't work for data in flash. There are only very few processor commands to access flash data. Therefore the compiler must create special ( relative awkward ) code if it needs to access data in flash. That is usually not done. Only when the PROGMEM keyword is used, the compiler will create this special code. That's why even constant data is usually first copied to RAM and then accessed from there within the program.
Other processors which can access flash or RAM with the same commands don't have this problem and with this processors PROGMEM is simply ignored. Constant data is never copied to RAM and directly accessed from flash always. But this is not possible for AVR processors.

For completeness - if you have a simple const variable (not an array) it may or may not take up RAM space. If the compiler can generate an immediate instruction for the value (typically small integers) it may not be stored in RAM at all. The difference in RAM usage and code size is minimal and probably only of academic interest.

Actually even a variable may not be stored in RAM. If the compiler can keep it in a register it may never be stored in RAM. This is of interest if you want to look at a variable in a debugger.