Накладные расходы производительности для частых (5 Гц) сохранений основных данных

Для приложения iPhone, которое воспроизводит аудиофайлы, я работаю над системой, чтобы отслеживать прогресс пользователя в любом эпизоде, который они прослушали (например, они слушают первые 4: 35 file1, затем запускают другой файл и возвращаются к file1, и он начинается в 4:35).

Я настроил базовую модель данных для хранения метаданных, но мне интересно, насколько агрессивно я могу/должен кэшировать текущее местоположение во время воспроизведения.

В настоящее время я только что вставил вызов save: в метод, который был ранее использовался для обновления меток времени и uislider playhead. Этот метод вызывается NSTimerInterval каждые 0,2 секунды.

0,2 секунды - это намного больше точности, чем мне нужно, чтобы отслеживать прогресс кэша. Значения в любом случае округляются до ближайшей секунды, поэтому по существу 4/5 каждого сохранения является избыточным.

Учитывая, однако, что это в значительной степени все основные данные, это только только когда-либо имеет дело с одним значением для одной записи в любой момент времени. время, я задаюсь вопросом, Имеет ли смысл просто делать дополнительные, ненужные save: s, или управлять вторым таймером для выполнения обновления реже.

Как есть, Instruments сообщает длительность сохранения каждого события как ~800, достигая максимума около 2000. Я не совсем уверен, как интерпретировать эти результаты. Фактическая производительность приложения в симуляторе, по-видимому, не оказывает существенного влияния.

Если этот вид сохранения настолько дешев, что имеет смысл поддерживать низкую сложность кода (только управление a один таймер), я бы оставил все как есть, но мой инстинкт подсказывает, что это много операций, независимо от того, насколько дешево.