Времена и процедури :)

Здравейте,
вчера докато се бъзиках с писане един манипулатор на данни, реших да си направя тест за скороста на кода (брой операции за еденица време). Процедурите се състоят от обръщения към WinXP (т.е. използвам само Windows standart library) и след наоколко теста забелязах следния резултат за следният код:
//това е процедурата, за която се измерва времетраенето
void f()
{
char buffer[100];
CManipData db;
db.Open("file_1.dat", "file_2.dat");

for(int i = 0; i < 100; ++i)
{
db.SelectKey(&i, sizeof(int));
db.ReadData(buffer, 100);
}
db.Close();
}
Ето и кое не разбрах,
когато "i" е до 100 време = 0.030 - 0.035 сек.
когато "i" е до 500 време = 0.080 - 0.090 сек.
когато "i" е до 1000 време = 3.30 - 3.50 сек.
(правени са по 10 опита)
Защо времето за изпълнение скача нелинейно, ами скокообразно?
И това поведение на виндоуса ли е, или повредата е в моя дизайн
Някаква идея? Мерси предварително

01011001

Анкета (от 10 въпроса) направена измежду 3ма участници живеещи в един и същи дом не е представителна за цялото село...

Врътни ги малко повече пъти тия i-та де

Може докато са много малки да се събират нещата в кеша на пор-цесора

Работа с файлове, кешове разни... какъвто и резултат да получиш, според мен все ще е лъжлив.

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

Повредата си е в твоя дизайн:-)

И как очакваш времето да бъде пропорционално само не разбрах?:-)
Знаеш ли какво става с динамичната памет и обекта някъде м/у 500 и 1000, а?:-)
След като буферната памет свърши, се създава нов обект:-)
Бас ловя, че ако цикъла е до 1 000 000 ще ти отнеме часове докато извадиш резултат:-)
Това е все едно да напишеш следното:

string s;
for (int i=0; i<=1 000 000; i++)
{
s +="kasjcsdkjcbsdjbcsdbc";
}

За повече опити с "i"-тата може и да пробвам, но като гледам колко време ще ми отнеме вероятно - забрави.
Относно отговора за буфера и динамичната памет ми се струва по-вероятно да е така, но в посоченият цикъл никъде не се заделят обекти (в процедурите също).
Аха ще пусна теста и на друга машинка, но мен като цяло не ме интересува нито скороста, нито съвместимоста, а защо подскача така времето на изпълнение
Мерси за отзивите

Файлови буфери?
Други програми да работят паралелно?
Кеша на процесора?

ПП
Както казах анкета между 3ма от една къща не е представителна за цялото село... Т.е. резултатите са с прекалено голяма допустима грешка... Бе да си го кажем направо - "неверни" са... или по-меко казано са неблагонадеждни...

Защото Windows не е RTOS. Някъде отдолу, под уютните функции на WinAPI-то, в мрачните подземия на кърнъла се крие чудовището HAL, което приема всяко извикване на функция като предложение да изпълни някаква работа. И когато на него му скимне, може и да я свърши. Това е основната причина да не можеш да засечеш време за работа с хардуер.

Втората причина е, че въобще във всяка мултитаскинг ОС изпълняваща се върху процесори на брой по-малко от тасковете имаш псевдопаралелна работа. Образно казано, за да си бръкне операционната система в носа, трябва да спре изпълнението на текущо изпълняваните процеси. А нуждата от бъркане в носа при Windows се появява сравнително често. И ако търгнеш да смяташ вероятности, можеш да си поставиш следния въпрос:

"По какъв начин влияе времето за изпълнение на дадена програма върху вероятността тя да бъде прекъсната поне веднъж", с начално условие последното бъркане в носа да е приключило точно преди стартирането на програмата.

И за тези които ги мързи да четат дивотиите ми, могат да се възползват от следния пример:

ВАРИАНТ 1 - Малък брой цикли

Време: Събитие:
-0001 Друг таск е приспан
00000 Таск на програмата роден и събуден
00001 Старт програма
-------------- изпълнение
00250 Край програма
00251 Таск на програмата приспан и застрелян


ВАРИАНТ 2 - Голям брой цикли

Време: Събитие:
-0001 Друг таск е приспан
00000 Таск на програмата роден и събуден
00001 Старт програма
-------------- изпълнение
00500 Таск на програмата приспан
00501 Друг таск събуден
... таскове се будят и приспиват...
01200 Друг таск е приспан
01201 Таск на програмата събуден
-------------- изпълнение
01500 Край програма
01501 Таск на програмата приспан и застрелян


и прочее. Във втория случай, мерейки времето ти мериш и времената за изпълнение на други таскове, които въобще не те засягат.

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

Ама и ти едно сравнение направи. Се едно ако е RTOS нема разни неща под съответние АПИ функции.

Лека нощ

Е за имане - има, ама поне хвърлят по едно око към часовника. Точно в момента се боря с едни бързовървящи кретенизми, и за туй се сетих за РТОС.

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

Като гледам най-разумно е да се съглася с повечето от вас, примирявайки се за пореден път, че софтуера ми съжителства с неопределени на брой и поведение други такива
Еехх.. като се замисля ще обърна внимание повече на микроконтролерите - там поне се знае какво става..
Мерси пак за отзивите.

01011001

Няма как, има неща с които човек трябва да се примири.

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

Също така зависи с какво измерваш времето. GetTickCount е малко по-зле от asm rdtsc примерно. Така ако си мерил с първото, грешката ти е ще е над 10мс и от първите два резултата няма да има смисъл. А второто, в наши дни, е в части от наносекундата.

Също така зависи с какво измерваш времето. GetTickCount е малко по-зле от asm rdtsc примерно. Така ако си мерил с първото, грешката ти е ще е над 10мс и от първите два резултата няма да има смисъл. А второто, в наши дни, е в части от наносекундата.

Струва ми се че проблема може да е в db.SelectKey(&i, sizeof(int));

Какво прави тази функция ?
Търси позиция из файла откъдето да почне четенето на данните или какво ?

Използвам GetThickCount, но това не е от кой знае какво значение за това което питах (ако е в рамките на 10 милисек. ;) )
В двете процедури се използват само ReadFile и SetFilePointer + х2 авт. променливи и толкоз.
Това което ме учуди изглежда наистина се дължи в случая на опер. система (кеш-меш и там изкуствения мултитаск)


01011001