Продолжаем серию охуительных историй про производительность простейших операций Итак, есть бенчмарк, который просто обходит большой массив и суммирует элементы http://ideone.com/UtpVej Запускаем под последней оракловой jvm: $ /opt/oracle-jdk-bin-1.8.0.20/bin/java Iter 100000000 0 -10621346557024: 43 $ /opt/oracle-jdk-bin-1.8.0.20/bin/java Iter 100000000 1 -10621346557024: 42 $ /opt/oracle-jdk-bin-1.8.0.20/bin/java Iter 100000000 2 -10621346557024: 48 Казалось бы логично — обход массиве в обратном направлении не cache-friendy Запускаем под айбиэмовской машиной: $ /opt/ibm/java-x86_64-71/bin/java Iter 100000000 0 -10621346557024: 107 $ /opt/ibm/java-x86_64-71/bin/java Iter 100000000 1 -10621346557024: 98 $ /opt/ibm/java-x86_64-71/bin/java Iter 100000000 2 -10621346557024: 90 Если отбросить тот факт, что работает медленно, можно отметить, что реализация обратного обхода и должна была работать быстрее, потому что в байткоде видно, что размер массива загружается всего один раз, а в реализации с прямым циклом по массиву его приходится получать каждый раз. В общем, я продолжаю охуевать от айбиэмовских jvm и продолжаю их использовать в силу более быстрого gc

Чо за хуйту я читаю: > Избегайте вызова функций с переменным количеством аргументов со своими собственными сигнатурами, даже если это вполне корректные функции из станартной библиотеки C, такие как sprintf. Вызовы sprintf часто выглядят более компактными и простыми для понимания, чем эквивалентные вызовы с использованием форматирования stringstream и операторов operator<< - так же как легче сесть в машину не оборудованую ремнями и подушкой безопасности, да еще и без дверей.

говно > Typed Racket’s local type inference algorithm is currently not able to infer types for polymorphic functions that are used on higher-order arguments that are themselves polymorphic.

Systems Programming with scsh. http://www.drdobbs.com/systems-administration-with-scsh/199101322

Откровения фаната статической типизации. http://eax.me/types-benifit/

Выкидывайте плюсы. http://ldeniau.web.cern.ch/ldeniau/cos.html

хвала утилите checkstyle и позор криворуким долбоёбам (мне). написал в коде: ```java if (cancelled) { throw new CancellationException(); } if (exception == null) { return result; } ``` Видите ошибку? А я вот в двенадцатом часу ночи не увидел: `EnterpriseShit.java:60: if at indentation level 10 not at correct indentation, 8`

специально для @lord: http://ideone.com/qG6C2N tl;dr: стандартная работа со временем в go такая же медленная как в джаве, а joda-time — рулит

Понадобилось мне из секунд с начала эпохи™ получать год и месяц. Итерация №0: Берём java.util.Calendar, делаем .setTimeMillis(...), делаем .get(Calendar.YEAR) и .get(Calendar.MONTH) (не забываем месяц на единицу увеличивать) Исследование №1: Запускаем под JProfiler, видим, что 16.3% времени занимает извлечение даты. Печалимся. Итерация №1: Видим, что в папке lib/ проекта уже лежит joda-time-2.0.jar. Делаем date = new DateTime(millis) и .get(DateTimeFieldType.year()) и .get(DateTimeFieldType.month()). Исследование №2: Запускаем под JProfiler, видим, что извлечение даты занимает уже 12.7%. «И увидел Бог, что это хорошо». Исследование №3: Хочется понять насколько реально быстрее работает joda-time: 1. Качаем joda-time-2.4 2. Пишем небольшой бенчмарк. 3. Запускаем 10kk итераций. Видим, что Calendar выполняет их за 789 мс, а joda-time — за 1126 мс. 4. Охуеваем 5. Чешем репу 6. Копируем из папки проекта joda-time-2.0.jar и запускаем с ним. Результат — 458 мс. Исследование №4: 1. Качаем бету Java 8 от IBM 2. Дописываем бенчмарк, который делает LocalDateTime.ofInstant(Instant.ofEpochMilli(millis), id).getYear() 3. Запускаем — 960 мс. Т.е. уже лучше Calendar, но всё ещё хуже joda-time-2.0. Выводы: Новое — не значит лучшее. Хочешь реально быстрого извлечения времени — создавай один объект MutableDateTime из joda-time и будет тебе счастье. Для истории, код бенчмарка: ```java import java.time.Instant; import java.time.LocalDateTime; import java.time.ZoneId; import java.time.temporal.ChronoField; import java.util.Calendar; import org.joda.time.DateTimeFieldType; import org.joda.time.DateTime; import org.joda.time.MutableDateTime; interface MillisToYear { int year(long millis); } class CalendarMillisToYear implements MillisToYear { private final Calendar cal = Calendar.getInstance(); @Override public int year(final long millis) { cal.setTimeInMillis(millis); return cal.get(Calendar.YEAR); } } class JodaMillisToYear implements MillisToYear { private final DateTimeFieldType year = DateTimeFieldType.year(); @Override public int year(final long millis) { return new DateTime(millis).get(year); } } class MutableJodaMillisToYear implements MillisToYear { private final DateTimeFieldType year = DateTimeFieldType.year(); private final MutableDateTime date = new MutableDateTime(); @Override public int year(final long millis) { date.setMillis(millis); return date.get(year); } } class Java8MillisToYear implements MillisToYear { private final ZoneId id = ZoneId.of("Europe/Moscow"); @Override public int year(final long millis) { return LocalDateTime.ofInstant(Instant.ofEpochMilli(millis), id) .getYear(); } } public class Main { public static void main(final String... args) { MillisToYear mty; switch (Integer.parseInt(args[0])) { case 0: mty = new CalendarMillisToYear(); break; case 1: mty = new JodaMillisToYear(); break; case 2: mty = new MutableJodaMillisToYear(); break; case 3: mty = new Java8MillisToYear(); break; default: throw new RuntimeException(); } long now = System.currentTimeMillis() / 86400000L * 86400000L; for (long i = 0; i < 1000000; ++i) { mty.year(now + i); } long start = System.currentTimeMillis(); long chksum = 0L; for (long i = 0L; i < 10000000000L; i += 1000L) { chksum += mty.year(now + i); } long total = (System.currentTimeMillis() - start); System.out.println("Total time: " + total); System.out.println("Checksum: " + chksum); } } ```

Чятик, как в твоем любимом говноязычке делается такая херня -> http://pasterack.org/pastes/18033 То есть нагенерить пачку классов (не объектов, так что JS-питухи сразу идут лесом), которые параметризованы лямбдочками. Я попытался сделать на говноплюсах и высрал примерно вот енто -> http://ideone.com/AZBy69 но чото кал какой-то.

> Today I am happy to make the first release of the Common Lisp implementation “Clasp”. Clasp uses LLVM as its back-end and generates native code. Clasp is a super-set of Common Lisp that interoperates smoothly with C++. The goal is to integrate these two very different languages together as seamlessly as possible to provide the best of both worlds. The C++ interoperation allows Common Lisp programmers to easily expose powerful C++ libraries to Common Lisp and solve complex programming challenges using the expressive power of Common Lisp. Clasp is licensed under the LGPL. лан // пошел думать почему у Racket JIT не на llvm.

Парни, у меня тут какой-то феерический майндфак. Есть такая читалка, CoolReader называется. В ней есть закладки и даже экспорт оных в файл. В коде написано, что файл в UTF-8, но при этом в него пишется BOM для UTF-16 (0xfeff то есть, вместо положенного 0xefbbbf): http://sourceforge.net/p/crengine/crengine/ci/cr3-3.1.2-33/tree/android/src/org/coolreader/crengine/BookInfo.java#l240 (ссылка на код той версии, что собран и работает у меня на Nook). По факту в файле BOM правильный, двухбайтовый. WTF?

норм ``` promote :: (Read a, Show b) => (a -> b) -> String -> StringSource promote2 :: (Read a, Read b, Show c) => (a -> b -> c) -> String -> String -> StringSource promote3 :: (Read a, Read b, Read c, Show d) => (a -> b -> c -> d) -> String -> String -> String -> StringSource promote4 :: (Read a, Read b, Read c, Read d, Show e) => (a -> b -> c -> d -> e) -> String -> String -> String -> String -> StringSource promote5 :: (Read a, Read b, Read c, Read d, Read e, Show f) => (a -> b -> c -> d -> e -> f) -> String -> String -> String -> String -> String -> StringSource promote6 :: (Read a, Read b, Read c, Read d, Read e, Read f, Show g) => (a -> b -> c -> d -> e -> f -> g) -> String -> String -> String -> String -> String -> String -> StringSource promote7 :: (Read a, Read b, Read c, Read d, Read e, Read f, Read g, Show h) => (a -> b -> c -> d -> e -> f -> g -> h) -> String -> String -> String -> String -> String -> String -> String -> StringSource promote8 :: (Read a, Read b, Read c, Read d, Read e, Read f, Read g, Read h, Show i) => (a -> b -> c -> d -> e -> f -> g -> h -> i) -> String -> String -> String -> String -> String -> String -> String -> String -> StringSource promote9 :: (Read a, Read b, Read c, Read d, Read e, Read f, Read g, Read h, Read i, Show j) => (a -> b -> c -> d -> e -> f -> g -> h -> i -> j) -> String -> String -> String -> String -> String -> String -> String -> String -> String -> StringSource promote10 :: (Read a, Read b, Read c, Read d, Read e, Read f, Read g, Read h, Read i, Read j, Show k) => (a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k) -> String -> String -> String -> String -> String -> String -> String -> String -> String -> String -> String ```

написал вчера новый функционал. подумал что выглядит недостаточно гармонично. и точно — при написании ещё одной ручки в коде обнаружил, что она целиком заменит вчерашний костыль

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

хётворк тупил в монитор, нервно кусал губы и ждал её — восьмую jvm от IBM

Как же заебывает писать на говносишке после божественной ракетки. Куча скобок, точкизапятые, половина ошибок - не поставил где-то скобочку или ;

это чувство, когда обнаруживаешь, что твои демоны на разных серверах сами между собой договорились и начали по сети вместо плэйнтекста слать гзипованные данные

Дают один 3D фреймворк напоразбираться в рабстве. @ До 5 утра субботы ебешься над туториалом, где нужно заанимировать движение шарика @ Шарик нихуя не движется @ С осознанием собственного ничтожества пиздуешь домой @ Лан