симулятор запускается на маке, дебаг происходит в студии. железный девайс надо тоже к маку подключать, что бы на нем дебажится.
В бесплатной версии ограничение при деплойменте в 32KB IL instructions в приложении, нет p/invoke.
что будет перерисовывать программа по перенстройке будильника?
если что, я указывал на некорректный тезис о том, что о энергопотреблении при считывании гироскопа можно судить по поведению программы для перевода будильника.
а почему ты решил что батарею садят обращения к датчику, а не исполнение программы, которая обращается к датчику, анализирует данные, сохраняет их в storage — в общем делает кучу вещей?
Добавь текстовый файл в проект, измени расширение .txt на .tt, после этого в контекстном меню появится «run custom tool» для ручной перегенерации, и как в 2010 студии будет автоматически перегенерироваться при сохранении изменений в tt.
зависит от доли cpp проектов (компиляция cpu bound).
у меня с#, ~60 проектов, 3 веб-сайта. на рамдиск замапплены папки BIN и OBJ из каждого проекта, ASP.NET Temporary Files (обе x64/x32), TEMP тоже на рамдиске. по измерениям procmon по время ребилда между этими папками у меня перемещается 2.6 GB данных.
конкретные замеры по времени я уже не вспомню, прирост получится в 3-4 раза, по perfmon при компиляции на hdd пики чтения/записи были ~8 MB/sec, при компиляции на ramdisk видны пики в ~90/sec.
Еще из наблюдений, компиляция website projects генерит очень много мелких файлов в TEMP/ASP.NET Temp, перенос их на ramdisk ускорил старт сайта после изменений в BIN/web.config.
самое главное — во время компиляции можно спокойно работать с другими программами (раньше тупило любое обращение к hdd, поискать в аутлуке было нереально)
у меня без тормозов. т.к. колибри как продукт видимо скорее мертв чем жив и апдейтов не дождешься, можно попробовать самостоятельно добавить индексы в базу колибри (sqlite, по полу items.title). по идее, это единственное место, из-за чего может тормозить при нормальном железе и не мертвой винде.
впрочем, у меня и без приседаний отлично работает (четыре сотни проиндексированных айтемов) на рабочем тазике загруженном по самое нехочу...
сдаюсь. т.к. я покидаю топик, объясню.
все не так сложно. windows тратит время на полную вычитку fat при вставке removable storage, логично считая что лучше один раз напрячь пользователя тормозами при вставке диска, чем потом много-много раз напрягать пользователя мелкими тормозами при обращении программ к файлам. представь ситуацию что вставленный cdrom поцарапанный, реактивность программы читающей файлы с диска будет изрядно испорчена. теперь представь что эта программа игра (не трогаем реализацию), что скажет массовый пользователь на просадки fps, даже если игра просто обращается к диску что бы взять следующую mp3 для проигрывания.
именно такое поведение (полная вычитка фат) я считаю адекватным. я собственно и ввязался в обсуждение после "залипает на некоторое время, переваривая его", задела некомпетентность + безаппеляционность.
[quote]Факт, что это выглядит непрофессиональным и заметно мешает в работе. [/quote]
имеет смысл посмотреть дальше своего носа. я нарочно не публикую ответ, предлагая найти его самому. в качестве урока, что ничего в этом мире не происходит просто так.
В бесплатной версии ограничение при деплойменте в 32KB IL instructions в приложении, нет p/invoke.
если что, я указывал на некорректный тезис о том, что о энергопотреблении при считывании гироскопа можно судить по поведению программы для перевода будильника.
подозреваю что автору хватило бы стандартной Windows Shadow Copy, но видимо свой велосипед интереснее.
у меня с#, ~60 проектов, 3 веб-сайта. на рамдиск замапплены папки BIN и OBJ из каждого проекта, ASP.NET Temporary Files (обе x64/x32), TEMP тоже на рамдиске. по измерениям procmon по время ребилда между этими папками у меня перемещается 2.6 GB данных.
конкретные замеры по времени я уже не вспомню, прирост получится в 3-4 раза, по perfmon при компиляции на hdd пики чтения/записи были ~8 MB/sec, при компиляции на ramdisk видны пики в ~90/sec.
Еще из наблюдений, компиляция website projects генерит очень много мелких файлов в TEMP/ASP.NET Temp, перенос их на ramdisk ускорил старт сайта после изменений в BIN/web.config.
самое главное — во время компиляции можно спокойно работать с другими программами (раньше тупило любое обращение к hdd, поискать в аутлуке было нереально)
впрочем, у меня и без приседаний отлично работает (четыре сотни проиндексированных айтемов) на рабочем тазике загруженном по самое нехочу...
все не так сложно. windows тратит время на полную вычитку fat при вставке removable storage, логично считая что лучше один раз напрячь пользователя тормозами при вставке диска, чем потом много-много раз напрягать пользователя мелкими тормозами при обращении программ к файлам. представь ситуацию что вставленный cdrom поцарапанный, реактивность программы читающей файлы с диска будет изрядно испорчена. теперь представь что эта программа игра (не трогаем реализацию), что скажет массовый пользователь на просадки fps, даже если игра просто обращается к диску что бы взять следующую mp3 для проигрывания.
именно такое поведение (полная вычитка фат) я считаю адекватным. я собственно и ввязался в обсуждение после "залипает на некоторое время, переваривая его", задела некомпетентность + безаппеляционность.
имеет смысл посмотреть дальше своего носа. я нарочно не публикую ответ, предлагая найти его самому. в качестве урока, что ничего в этом мире не происходит просто так.