История изменений
Исправление a--, (текущая версия) :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем Итератор по результатам поиска и считаем только первую страницу. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Необходимости в map<ПоисковаяСтрока,Итератор> нет. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей Итератором, из Другого Кэша
В тех редких случаях, когда поисковая строка оказывается с уничтоженным Итератором, а юзер хочет пройтись по Итератору (т.е. получить следующую поисковую страницу), Итератор создается заново, и заново заталкивается в LRU кэш.
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем Итератор по результатам поиска и считаем только первую страницу. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Необходимости в map<ПоисковаяСтрока,Итератор> нет. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей Итератором, из Другого Кэша
В тех редких случаях, когда поисковая строка оказывается с уничтоженным Итератором, а юзер хочет пройтись по Итератору (т.е. получить следующую поисковую страницу), Итератор создается заново, и заново заталкивается в LRU кэш.
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем Итератор по результатам поиска и считаем только первую страницу. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей Итератором, из Другого Кэша
В тех редких случаях, когда поисковая строка оказывается с уничтоженным Итератором, а юзер хочет пройтись по Итератору (т.е. получить следующую поисковую страницу), Итератор создается заново, и заново заталкивается в LRU кэш.
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем итератор по результатам поиска и считаем только первую страницу. Далее я его называю Итератор. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей Итератором, из Другого Кэша
В тех редких случаях, когда поисковая строка оказывается с уничтоженным Итератором, а юзер хочет пройтись по Итератору (т.е. получить следующую поисковую страницу), Итератор создается заново, и заново заталкивается в LRU кэш.
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем итератор по результатам поиска и считаем только первую страницу. Далее я его называю Итератор. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей Итератором, из Другого Кэша
В тех (редких) случаях, когда поисковая строка оказывается с уничтоженным Итератором, он создается заново, и заново заталкивается в LRU кэш.
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем итератор по результатам поиска и считаем только первую страницу. Далее я его называю Итератор. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей Итератором, из Другого Кэша
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем итератор по результатам поиска и считаем только первую страницу. Далее я его называю Итератор. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Но у LRU кэша есть обязанность обнулить ссылку на Итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей итератором, из Другого Кэша
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем итератор по результатам поиска и считаем только первую страницу. Далее я его называю Итератор. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Прямые адреса, гы-гы. Но у LRU кэша есть обязанность обнулить ссылку на итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей итератором, из Другого Кэша
Исходная версия a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Ха-ха. Щас расскажу случай, приближенный к реальности, с прямыми адресами.
Допустим, мы — Гугль. Юзер запросил поиск, который может дать 1000 результатов (100 страниц по 10 результатов). Мы, понятное дело, не считаем сразу 100 страниц, а создаем итератор по результатам поиска и считаем только первую страницу. Далее я его называю Итератор. Этот Итератор создается в пуле фиксированного размера и его прямой адрес записывается в LRU кэш.
Последние эн миллионов поисковых строк лежат в Другом Кэше, который тоже как-то управляется, но как — не важно. Рядышком с поисковой строкой лежит прямой указатель на Итератор. При выталкивании Итератора из LRU кэша указатель на него обнуляется и в кэше поисковых строк (т.к. Итератор внутри себя еще и содержит ссылку на поисковую строку в Другом Кэше). При выталкивании поисковой строки из Другого Кэша Итератор выталкивается и из LRU кэша тоже.
После выталкивания Итератора из LRU кэша и обнуления указателя на него рядом с поисковой строкой выполняется деструктор Итератора.
Таким образом у LRU кэша нет обязанности отвечать «где лежит Итератор» — это и так известно. Но у LRU кэша есть обязанность обнулить ссылку на итератор, выталкиваемый из LRU кэша по случаю:
1. недостатка места в LRU кэше (т.е. в пуле Итераторов)
2. выталкивания поисковой строки, владеющей итератором, из Другого Кэша