Windows 7, отключить это: (SystemRestore) ?

[Borjomy_1]

Я Вам разрешаю оставить функцию записи с открытием и закрытием файла. Только вынесите ее в отдельный цикл с передачей данных через очередь.

[Artem.spb]

а это, как стоит сделать

[dadreamer]

Artem.spb, я бы всё-таки запихнул Flush после последней записи, больше для уверенности, а то всякое бывает: то ли система свободна и пишет сразу же, то ли занята и пишет через минуту-другую. Кстати говоря, ссылки в цикле можно гонять не в сдвиговом регистре, а в обычном туннельном (если, конечно, не закрыли файл и не открыли заново). Сссылка в течение одного запуска программы не меняется.

[Artem.spb]

Artem.spb, я бы всё-таки запихнул Flush после последней записи, больше для уверенности, а то всякое бывает: то ли система свободна и пишет сразу же, то ли занята и пишет через минуту-другую.

согласен, но это уже частности, допиливание напильником так сказать.

Кстати говоря, ссылки в цикле можно гонять не в сдвиговом регистре, а в обычном туннельном (если, конечно, не закрыли файл и не открыли заново). Сссылка в течение одного запуска программы не меняется.

можно. но я по привычке в регистр, т.к. часто приходится по смене дня/месяца новый файл создавать.

[Jakob Brontfeyn]

Jakob Brontfeyn, Операция записи в файл никем не лимитирована. Она может занимать (и это никакой не баг) и несколько секунд и несколько микросекунд.

Спасибо за идею, я просто возьму померяю и сохраню в
в фаиле, как это время в милисекундах изменяется
в течении нескольких суток.

[Borjomy_1]

Jakob Brontfeyn, Бесполезная идея. Вы должны понимать, что это время может сильно различаться (причем вы никогда не сможете смоделировать все ситуации), и делать программу, для которой это время становится принципиально не критично, главное, чтобы среднее время записи не превышало время основного цикла. И так понятно, что время записи может иногда превышать несколько секунд, т.е быть больше времени цикла в несколько раз.
Не понимаю, почему вы показываете нулевую реакцию на предложение о разведении чтения и записи в файл в разные циклы.

[Jakob Brontfeyn]

Jakob Brontfeyn, Бесполезная идея. Вы должны понимать, что это время может сильно различаться (причем вы никогда не сможете смоделировать все ситуации), и делать программу, для которой это время становится принципиально не критично, главное, чтобы среднее время записи не превышало время основного цикла. И так понятно, что время записи может иногда превышать несколько секунд, т.е быть больше времени цикла в несколько раз.
Не понимаю, почему вы показываете нулевую реакцию на предложение о разведении чтения и записи в файл в разные циклы.

Не торопитесь, практика критерий истины, смотрите на базе моего примерчика (не округляя до 4К).
Результаты впечатляют ну например это 200 строчек примерно 25 килобайт
устойчиво запосываются за 0 мс, вдвое меньший обьем 100 строчек устойчиво пишется за
1 мс, чудеса, там наверное старый библиотекарь записью на диск руководит.
Книги потолще кидает сразу в большие свободные места не задумываясь, а для более тонких
долго ищет подходящую минимальную щель на полках.
Впрочем каждый имеет возможность сам проверить на своих компах, и сделать свои выводы,
это я дома проверял, сейчас пора на работу.

[Borjomy_1]

Jakob Brontfeyn, Вы это проверяли в спокойной обстановке или на фоне работы какого-нибудь тяжелого инсталлятора? Предупреждаю вас! ))) Вы попадаете на те-же грабли. Ничего удивительного в том, что лучшее время записи составляет меньше 1мс. Скорость обмена с ЖД от 30Мб/с, в таких условиях вы другого результата и не получите. Только ваша программа не одна такая. И проблемы появляются, когда другой процесс занимает весь трафик с ЖД. Вот тут вы ожидаемо сядете в лужу.
Любая windows НЕ ЯВЛЯЕТСЯ СИСТЕМОЙ РЕАЛЬНОГО ВРЕМЕНИ. В это понятие входит и гарантированное время обмена с накопителем.

[Jakob Brontfeyn]

Jakob Brontfeyn, Вы это проверяли в спокойной обстановке или на фоне работы какого-нибудь тяжелого инсталлятора? Предупреждаю вас! ))) Вы попадаете на те-же грабли. Ничего удивительного в том, что лучшее время записи составляет меньше 1мс. Скорость обмена с ЖД от 30Мб/с, в таких условиях вы другого результата и не получите. Только ваша программа не одна такая. И проблемы появляются, когда другой процесс занимает весь трафик с ЖД. Вот тут вы ожидаемо сядете в лужу.
Любая windows НЕ ЯВЛЯЕТСЯ СИСТЕМОЙ РЕАЛЬНОГО ВРЕМЕНИ. В это понятие входит и гарантированное время обмена с накопителем.

Я всю субботу и воскресенье занимался Лабвью,
вместо того чтобы культурно отдыхать.
Проверять буду на реальных лабораторных компах,
если удасться вклинится, на всех идут эксперименты и
они все благополучно пережили два выходных дня, так что настроение
у меня хорошее. Проверил на своем бюрошном компе и установил
интересную закономерность. Если обьем кратный 12К пусть даже с остатком (до 4К),
время записи стабильно 0 мс, независимо от обьема который пишется, в других случаях 1мс,
добавил округлятор до 4К. Смотрите пример.

[Vitekkz88]

Jakob Brontfeyn писал(а):Если обьем кратный 12К пусть даже с остатком,
время записи стабильно 0 мс, независимо от обьема который пишется, в других случаях 1мс,
добавил округлятор до 4К. Смотрите пример.

Win7 x64, Core i7 CPU 3.4 GHz, 16GB ОЗУ.

[Jakob Brontfeyn]

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

[Borjomy_1]

Jakob Brontfeyn,
Ну что вы, как девочка, упрямитесь? Ставьте передачу через очередь, как показано в моей модификации, и забудьте о проблеме навсегда. Повторяю вам еще раз. Ваше решение изначально неправильное. Не говоря уже о том, что вы, как экспериментатор, должны понимать, что время выполнения записи - изначально НЕИЗВЕСТНАЯ ВЕЛИЧИНА. Измерить-то ее можно, а вот предугадать нельзя. Ее гауссиана с бесконечно широкими крыльями. Да, 99.99% укладывается в 1000 мс. Но у вас возникает проблема на этих 0.01%. Либо вы на это забиваете, либо вы принимаете меры по разведению частотнозависимой и асинхронной частей вашей программы.

В своей программе вы набираете буфер. Это проблемы никак не решает. Единственный результат вашей модификации - реже производится запись. Т.е вы УМЕНЬШАЕТЕ вероятность неприятного события. Но принципиально его не устраняете. Я даже не знаю, как это назвать: латание ли тришкиного кафтана или маскирование проблемы...

[Jakob Brontfeyn]

Спасибо коллега, что так проникнулись моей проблеммой,
я слепил сам себе маленький примерчик для лучшего понимания как
функционирует очередь, чтобы все пощупать там и увидеть своими глазами
вот посылаю. Буду думать, может все таки в моем случае сделанный
суб-виайкой буфер в глобальной переменной подойдет лучше,
не так сильно будет меняться вся структура, пока не знаю, не решил.
Ну по времени которое занимает запись я уже писал,
оптимально 12К*n<=обьем(Kвyte)<12К*n+4 у меня стабильно 0 мс
Да и еще одно, все таки метод снижение вероятности неприятного события
до практически нулевых величин тоже имеет право на существование.
Невероятное и невозможное часто синонимы.

[Borjomy_1]

Невероятное и невозможное часто синонимы.

Но в вашем случае это не является невероятным, собственно, вы сами эту проблему и подняли. И ситуация, вообще-то, вполне закономерная.
С точки зрения надежности буфер вреден и от него надо избавляться. Очередь сама по себе является такой структурой, которая превращается в буфер только при возникновении задержек на этапе вычитывания из очереди ( в вашем случае - это операция записи). Поэтому буфер+очередь - это масло масляное.

[Jakob Brontfeyn]

Будем пробовать, вот сделал усовершенствованный пример с псевдо
"save", причем с помощью "hold" все равно обязательно создам задержку в 00:00
по 1 минуте в обе стороны, это самое плохое время для семерки.
Существуют ли ограничения на максимальный размер очереди в килобайтах?