- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
// https://github.com/vk-com/kphp-kdb/blob/ce6dead5b3345f4b38487cc9e45d55ced3dd7139/bayes/bayes-data.c#L1966
int init_all (kfs_file_handle_t Index) {
int i;
log_ts_exact_interval = 1;
ltbl_init (&user_table);
bl_head = qmalloc (sizeof (black_list));
black_list_init (bl_head);
int f = load_header (Index);
jump_log_ts = header.log_timestamp;
jump_log_pos = header.log_pos1;
jump_log_crc32 = header.log_pos1_crc32;
int user_cnt = index_users = header.user_cnt;
if (user_cnt < 1000000) {
user_cnt = 1000000;
}
assert (user_cnt >= 1000000);
user_cnt *= 1.1;
while (user_cnt % 2 == 0 || user_cnt % 5 == 0) {
user_cnt++;
}
ltbl_set_size (&user_table, user_cnt);
users = qmalloc (sizeof (user) * user_cnt);
for (i = 0; i < user_cnt; i++) {
user_init (&users[i]);
}
LRU_head = users;
LRU_head->next_used = LRU_head->prev_used = LRU_head;
if (f) {
try_init_local_uid();
}
if (index_mode) {
buff = qmalloc (max_words * sizeof (entry_t));
new_buff = qmalloc (4000000 * sizeof (entry_t));
}
return f;
}
Follow us!
А вообще, типичный олимпиадный код
большинство баз в лоб считают количество строк в таблице по индексу. как ты это не кэшируй, как ты там деревья и хэши не строй - уже на миллион записей в таблице это становится весьма заметным числом.
Ты думаешь там большая-большая таблица users в реляционной бд?
В частности http://codeforces.com/blog/entry/53274
мама дорогая
Можно бесконечно обсирать олимпиадный код, но это бессмысленно.
Подозреваю, что и в других СУБД поддержка транзакций и построчной блокировки тоже приведёт к «дорогому» count().
Вообще говоря желание знать количество записей в реальном времени выглядит подозрительно.
Если это база живых транзакций (OLTP) то в ней конечно могут быть нужны точные данные в реальном времени, но записей там обычно очень мало.
Если же это база для отчетов/аналитики (OLAP) то там во-первых обычно не нужны данные с точностью до хомячка (хватит и примерно) а если уж нужны то отчет можно построить и за ночь, оффлайново.
А хранить "активных пользователей сайта" в базе и каждый раз их считать это как-то странно.
Всё равно 99.999% юзеров не догадаются.
1. Всё равно 99.999% юзерам это число в точном виде не нужно.
2. Всё равно через пару минут младшие разряды можно выбрасывать.
Мгновенное количество никому снаружи ВК не нужно, усреднённое за время хорошо аппроксимируется формулой.
> инкрементить кол-во юзеров в JS - это самое оптимальное
И, возможно, даже по точности не/не сильно уступает реальному вычислению этого количества.
Это обоснованная оптимизация, что бы там ни говорили.
Карл Фридрих Гаусс отмечал: «Недостатки математического образования с наибольшей отчётливостью проявляются в чрезмерной точности численных расчётов».
Пятого-десятого, второго нам сюда
Потому что это плохая примета?
А вообще нормально в няшной юзать int когда есть типы явного размера?
И что такое f ?
Это чемпион Питера по спортивному программированию среди учащихся 11 классов писал?
Умножать int на не целое чисто это какое-то очень сильное колдунство.
Очень важный ассерт.
А что если во вкудахте будет настолько много пользователей, что при умножении их количества на 1.1, будет получаться число, которое в int уже обратно не влазит? Население земного шара - 7,442 миллиарда, это 7 422 000 000, а INT_MAX это на большинстве платформ всего-навсего 2 147 483 647. Ну ок, допустим что во вконтакте зарегалось 2 147 483 000 людей
И вот тут 2147483000 умножается на 1.1 (неявно кастуясь при этом в плавучего питуха) и потом кастуется обратно в int, но это число в int не влазит, мы натыкаемся UB, см. https://stackoverflow.com/a/526283
> To answer your question: The behaviour when you cast out of range floats is undefined or implementation specific.
> Speaking from experience: I've worked on a MIPS64 system that didn't implemented these kind of casts at all. Instead of doing something deterministic the CPU threw a CPU exception. The exception handler that ought to emulate the cast returned without doing anything to the result.
В общем, не туда олимпиадники ассерт втулили
> qfree
Похоже вконтакте написан на Qt.
вконтакте все очень быстрое просто
если сортировка то qsort
если аллокатор то qalloc
сопроцессор фирмы cray
можно срать в два унитаза
в сорок тысяч раз быстрей
Пиздец теперь усложнили свой пиздеж до языка си