From my own personal experience, calling setData() itself does not cause anything to be written to the FIT file -- it only sets the *next* value to be written (whether it's the once-per-second value, the lap value, or the session value.)

As a matter of fact, if you call setData "too early" (e.g. for the lap), then call it again, the final call before the value is actually written wins.

Looks like the docs explain this now:

developer.garmin.com/.../Field.html

function compute(sensor) {
    if( sensor != null ) {
        var HemoConc = sensor.data.totalHemoConcentration;
        var HemoPerc = sensor.data.currentHemoPercent;

        // Hemoglobin Concentration is stored in 1/100ths g/dL fixed point
        mCurrentHCField.setData( toFixed(HemoConc, 100) );
        // Saturated Hemoglobin Percent is stored in 1/10ths % fixed point
        mCurrentHPField.setData( toFixed(HemoPerc, 10)  );

        if( mTimerRunning ) {
            // Update lap/session data and record counts
            mLapRecordCount++;
            mSessionRecordCount++;
            mHCLapAverage += HemoConc;
            mHCSessionAverage += HemoConc;
            mHPLapAverage += HemoPerc;
            mHPSessionAverage += HemoPerc;

            // Updatea lap/session FIT Contributions
            mLapAverageHCField.setData( toFixed(mHCLapAverage/mLapRecordCount, 100) );
            mSessionAverageHCField.setData( toFixed(mHCSessionAverage/mSessionRecordCount, 100) );

            mLapAverageHPField.setData( toFixed(mHPLapAverage/mLapRecordCount, 10) );
            mSessionAverageHPField.setData( toFixed(mHPSessionAverage/mSessionRecordCount, 10) );
        }
    }
}

Not a big deal - but I wonder if you only write to the FIT when a value changes (and say it only changes once an hour or so).... if writing it every second (3599 extra writes)... causes more compute load and a larger file size? Or if that "static" value is written every time regardless? I know the graphs shown in Garmin Connect are the same regardless of writing the same value over and over, or just writing it when it changes.

Smart recording will save things like GPS "when needed" vs every second.  So if you don't move that far in a second, it won't save GPS that often.  It's meant to reduce the size of the .fit file.

I think it's not just legacy from when devices had less memory, but also it reduces the time for sync, storage on servers, etc.

Fair enough. I'll just say for my purposes I prefer to have as much data as possible, because it's not 100% clear from Garmin's description whether data is actually lost or not when smart recording is enabled. (If the two sets of data were completely equivalent, why would 1-second recording be a feature at all?).

www.dcrainmaker.com/.../configure-watches-datafields.html

This is what DC Rainmaker said back in 2016:

Hi Ray, why do you use 1 second recording instead of Smart Recording on your Garmin Edge? Is it any better? I though to leave it at Smart recording to reduce battery use!?

It’s so I don’t ‘lose’ data. Smart recording only records every 3-7 seconds (typically), so I’d lose bit of heart rate data or running data (i.e. cadence). Now in cycling with a power meter, the unit actually always records in 1-second, regardless of what you set it as.

As for battery, nope, zero impact there. The only thing it impacts is storage, but even that is a holdover from the old days. So much so that Garmin’s latest wearable (Vivoactive HR) goes to just 1-second recording, ditching smart recording.

Record something with smart and then the same thing with 1 sec.  Save both and use them to playback in the sim.  It's really easy to see.

Reqardless of smart vs 1 sec, the device sees everything at 1 sec, so things get calculated at the same rate.

Would you have a link to DCR's writeup on CIQ from 2015?  Reading it today would make me laugh.

Well, just to be safe, I enable 1 second recording anyway.

"Reqardless of smart vs 1 sec, the device sees everything at 1 sec, so things get calculated at the same rate."

Sure, but the question is does smart recording throw anything away? If smart recording and 1 second recording were 100% equivalent, then I would have a tough time understanding why 1-second would even be an option, unless some services just can't handle smart recording. (But it seems that everyone would have to, since that was the default on older watches.)

I have seen some old posts (10 years old) implying that data is lost when smart recording is enabled. I guess only garmin knows for sure.

Looking at this Garmin support article, it's implied that data is lost (IMO):
https://support.garmin.com/en-US/?faq=xQvHXbfaT27Zr4hxZDvjv5

"The difference between these options can be seen in the image below. The upper track represents Smart Recording while the lower track represents Every Second Recording."

Those two tracks don't look equivalent to me.

Here's something from training peaks which doesn't really settle the question either way.

https://help.trainingpeaks.com/hc/en-us/articles/204070064-What-is-the-difference-between-every-second-and-smart-recording-

"When there are too many gaps between recorded data points, TrainingPeaks is unable to fully populate workout data from graphs to route maps.  If you are seeing gaps in your workout graph and/or an inaccurate route map for your workout, check to see if you have Smart Recording turned on.  Turn it off if it is on and see if this resolves your issues. "

"Would you have a link to DCR's writeup on CIQ from 2015?  Reading it today would make me laugh."

www.dcrainmaker.com/.../connect-iq-intro.html

Based on this advice, you could just call setData() when values have changed. Or you could do what I do and call setData() as often as possible (in compute()).

thanks a lot this answers my question