Спасибо за отличную статью! Можете пояснить вот этот кусочек кода в get?
if (mapHot.contains(key)) {
// add & trim (LRU)
mapHot.add(key);
sizeHot += safeSizeOf(key, mapValue);
trimMapHot();
}
Насколько я понимаю, в случае если ключ находится в hot вы добавляете его туда опять чтобы поменять позицию в LinkedHashSet?
Но если это так, то оно не будет работать как запланировано — из документации к LinkedHashSet:
Note that insertion order is not affected if an element is re-inserted into the set. (An element e is reinserted into a set s if s.add(e) is invoked when s.contains(e) would return true immediately prior to the invocation.)
Ну и можно проверить:
LinkedHashSet<Integer> lhs = new LinkedHashSet<Integer>();
lhs.add(1);
lhs.add(2);
lhs.add(3);
lhs.add(1); // Add again, try to change position
for (Integer v: lhs)
System.out.println(v);
=>
1
2
3
И почему вы увеличиваете sizeHot, хотя элемент же уже был в множестве, ведь размер не поменялся?
Даже заплатив за подписку, вы не можете смотреть весь контент. Только то, что в данный момент разблокировано по желанию левой пятки.
Я все-таки понял так, что левая пятка принадлежит просматривающему.
В любой момент времени вы можете выбрать, какие серии вы хотите просмотреть, остальные на это время становятся неактивными (серыми). Закончив просмотр, вы можете выбрать другие серии для просмотра.
То есть это какой-то запрет в духе «нельзя смотреть более 5 серий в разных вкладках»
Метод Symbol#to_proc — это не основы языка, а новая фича языка 1.9. Я избегаю подобные конструкции, поскольку иногда приходится поддерживать код написанный под 1.8.
С кодом все замечательно, он демонстрирует то, что GIL не спасает от проблем синхронизации в коде приложения: строка вроде бы как должна напечататься один раз, а печатается несколько.
А вы попробуйте так написать — интересно удалит ли MariaDB GROUP из такого запроса.
Потому что насколько я понимаю эту оптимизацию, она в качестве неявного предположения как раз использует то, что в запросе не будут выбираться поля, не участвующие в группировке. В вашем же случае (когда такие поля выбираются) «GROUP BY without a corresponding HAVING clause is equivalent to a DISTINCT» становится неверным.
Множественное наследование же, или тут скрыто что-то сильно большее?
Пример на C++:
class A {
public:
int x;
void F1() {
std::cout << "I'm A: " << x << std::endl;
}
};
class B {
public:
int y;
void F2() {
std::cout << "I'm B: " << y << std::endl;
}
};
class C : public A, public B {
public:
int z;
void F3() {
std::cout << "I'm C: " << x << " and can call A and B" << std::endl;
F1();
F2();
}
};
Можно SD, нужно только использовать соответствующий образ.
Более того, до недавнего времени Linux на eMMC заводить не удавалось и для него пока SD — основной вариант.
WiFi/IO тоже не всегда нужны — в медиацентре, например, я не знаю зачем они.
Насколько я понимаю, в случае если ключ находится в hot вы добавляете его туда опять чтобы поменять позицию в LinkedHashSet?
Но если это так, то оно не будет работать как запланировано — из документации к LinkedHashSet:
Ну и можно проверить:
И почему вы увеличиваете sizeHot, хотя элемент же уже был в множестве, ведь размер не поменялся?
Также, если не хочется работать с ними напрямую, есть поддержка в ScalikeJDBC: github.com/scalikejdbc/scalikejdbc-async
Если тело имеет сферическую поверхность, то оно излучает по всей свой поверхности (4*pi*R^2), а поглощает только проходящее через сечение (pi*R^2).
Получается 278.6K
Ну как-то не очень все-таки. Взять хотя бы ваш пример:
vs
vs
Я все-таки понял так, что левая пятка принадлежит просматривающему.
То есть это какой-то запрет в духе «нельзя смотреть более 5 серий в разных вкладках»
ruby-doc.org/core-1.8.7/Symbol.html#method-i-to_proc
Хотя в контексте скрипта действительно стоит сделать новую, наверное.
Потому что насколько я понимаю эту оптимизацию, она в качестве неявного предположения как раз использует то, что в запросе не будут выбираться поля, не участвующие в группировке. В вашем же случае (когда такие поля выбираются) «GROUP BY without a corresponding HAVING clause is equivalent to a DISTINCT» становится неверным.
А с чем тогда связано то, что производительность STL контейнеров на втором графике тоже несколько выше?
Пример на C++:
В точности, как в документации — docs.puppetlabs.com/puppet/2.7/reference/lang_conditional.html
Ну и в Ruby этот код просто некорректен.
Более того, до недавнего времени Linux на eMMC заводить не удавалось и для него пока SD — основной вариант.
WiFi/IO тоже не всегда нужны — в медиацентре, например, я не знаю зачем они.