Как смоделировать нормальную производительность жесткого диска на моем Mac с твердотельным накопителем?

Чего я хочу

Я хочу смоделировать производительность обычного жесткого диска на моем компьютере для разработки на основе SSD.

Фон

Я разрабатываю приложение Mac на Macbook с SSD. Это великолепно быстро.

Если у кого-то есть стандартный жесткий диск, мое приложение будет для них медленнее. Мое приложение также интенсивно использует Core Data, поэтому скорость доступа к диску будет важным фактором.

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

Что я пробовал

Прежде чем установить свой SSD, я измерил производительность своего приложения в Instruments. После установки я снова измерил его, и оба теста были идентичными.

Это не имеет смысла для меня. Я убежден, что я сделал что-то не так здесь. Инструменты, вероятно, измеряют тактовую частоту, а не скорость настенного времени. Но все же, неужели скорость винчестера должна влиять на взятый мной бенчмарк? Или Instruments это как-то компенсирует?


cocoa performance solid-state-drive instruments
person John Gallagher    schedule 18.05.2011    source источник
comment
Почему бы просто не подключить внешний жесткий диск и не использовать его для тестирования?   -  person Paul R    schedule 18.05.2011
comment
Какой инструмент вы использовали?   -  person Eiko    schedule 18.05.2011
comment
@PaulR Я не могу изменить каталог, в котором находится мое хранилище данных, поэтому он всегда должен находиться на моем локальном диске. Я тоже везде ноут с собой беру и внешний таскать не хочу.   -  person John Gallagher    schedule 18.05.2011
comment
@Eiko By Instruments Я имею в виду инструмент производительности, который Apple предоставляет с инструментами разработчика OS X. Вот как это называется.   -  person John Gallagher    schedule 18.05.2011
comment
Если каталог жестко задан (а этого на самом деле быть не должно), вы можете использовать символическую ссылку на каталог на внешнем диске. Или вы можете сделать внешний диск загрузочным для целей тестирования. А что касается ношения внешнего диска, то они очень маленькие, и, по-видимому, вам не нужно постоянно тестировать производительность?   -  person Paul R    schedule 18.05.2011
comment
@John Gallagher Да, но какой инструмент из десятков вы использовали? Внутри Instruments так много разных инструментов.   -  person Eiko    schedule 19.05.2011
comment
@Eiko О, извините, совершенно неправильно понял. Профилировщик времени.   -  person John Gallagher    schedule 19.05.2011
comment
@PaulR Хммм. Хорошая точка зрения. Что касается жесткого кодирования, я просто использую стандартный шаблонный код Apple, чтобы найти каталог поддержки приложений пользователей. Еще не удосужились разрешить пользователю выбирать, где хранить данные. Идея символической ссылки звучит как лучший вариант на данный момент. Спасибо!   -  person John Gallagher    schedule 19.05.2011

Ответы (2)


arrow_upward
4
arrow_downward

Престижность @PaulR выше, который предложил использовать внешний жесткий диск USB для проверки производительности. Спасибо!

person John Gallagher    schedule 10.11.2011

arrow_upward
2
arrow_downward

Вы можете использовать виртуальную машину и регулировать доступ к диску. Таким образом, вы должны иметь контроль над скоростью диска... по-прежнему невозможно ограничить только запись или только чтение.

Вот несколько советов о том, как это сделать в Virtualbox 5.8. Ограничение пропускной способности для образов дисков https://www.virtualbox.org/manual/ch05.html#storage-bandwidth-limit

person Adi Roiban    schedule 22.10.2014
comment
Это хороший ответ для большинства людей. Проблема в том, что жесткие диски ведут себя по-разному, помимо того, что они медленнее. Как вы, наверное, знаете, жесткие диски непропорционально страдают от времени поиска. В моем случае мне нужно реальное поведение жесткого диска, так как я пытаюсь запустить атаку по времени на основе индексов файловой системы. - person sudo; 15.05.2016