- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
public abstract class BaseDateTime
extends AbstractDateTime
implements ReadableDateTime, Serializable {
/** The millis from 1970-01-01T00:00:00Z */
private volatile long iMillis;
/** The chronology to use */
private volatile Chronology iChronology;
/////////////////////////////////////////////////////////////////
/*
* DateTime is thread-safe and immutable, provided that the Chronology is as well.
* All standard Chronology classes supplied are thread-safe and immutable.
*
* @see MutableDateTime
*/
public final class DateTime
extends BaseDateTime
Любителям joda-time.
Cмущает меня этот volatile, который приходит в немутабельный класс от родителя.
Follow us!
Но я говорю что в мутабельном наследнике надо было volatile-поля сделать, а в немутабельном - final.
Ведь доступ идёт по геттерам через интерфейс.
Я раньше его редко использовал. Но вот теперь смотрю пристально, а тут хуйни всякой хватает.
new DateTime(null) - не кидает NPE, а создает DateTime.now().
Кстати аргумент Object (а доступны Date, Calendar и String) - можно и проебать. Зачем убирать типобезопасность - неясно. Это не жс, не пхп и не питон.
Ну и совсем классика типа
if (iOffsetParsed == true) {
return this;
}
Там проёбут, тут экономят. Авторы, то разные!
http://sourceforge.net/p/joda-time/bugs/153/
я всегда предпочитаю лочить или интерлок юзать
>DateTime is thread-safe and immutable
А в хацкеле поцоны как-то обходятся.
А разве immutable может быть не threadsafe? Ну кроме случаев с утечкой this из конструктора.
>кроме случаев с утечкой this из конструктора
Ради прикола конечно можно соорудить такой объект.
Неужели?
А чего так?
let x = 2
x =3
А если переменные нельзя менять, то и проблем к доступу к ним нет
Весьма полезны для коммуникации их функцианальные аналоги - MVar-ы (коробки с последовательным доступом, по сути синхронизированные каналы без буфера). Локи иногда просто вынесены в рантайм.
> Производительность volatile сильно зависит от архитектуры процессора. У интела чтение довольно дешевое, запись немного дороже.
Простите за хабр, но статью писал вменяемый человек.
http://habrahabr.ru/post/143390/
Вот тесты на интеле. Просто убираем чтение лишнего volatile. Всего-то.
Если не знаете специфики лучше молчите.
если у тебя программа так часто опрашивает время,
Гыгы.
http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.RequestSp ecificProcessorFactoryFactory.html
Кроме того, в том тесте из багтрекера предполагается low contention использование, в такой ситуации разница в чтении volatile и обычных полей минимальна на интеле. В условиях high contention, действительно, чтение volatile может стать довольно дорогим. Запись же я вобще здесь не рассматриваю, т.к. для иммутабельного DateTime запись происходит однажды при инициализации, и она явно сильно дешевле создания самого класса.
К слову, запустил я тест на 1.5.2 и 2.1 версиях с volatile и без volatile (i5, java 6, ubuntu 13.04 x86). В рамках одной версии разница между volatile и не-volatile около ~3% (не задрачивался с точностью, так как не суть). В то же время, разница между 1.5.2 и 2.1 огромна, 2.1 медленне 1.5.2 в ~10 раз. Насколько я понял, разница возникает из-за добавленного в 2.0 фрагмента в DateTimeZone.getOffsetFromLocal() ( http://sourceforge.net/p/joda-time/svn/1596/tree//trunk/JodaTime/src/main/java/org/joda/time/DateTimeZone.java?diff=1595 ), который вызывает дорогой метод previousTransition(), включающий Array.binarySearch() и довольно много другого кода.
Выводы:
1. Performance regression действительно имеет место быть при обновлении с 1.х до 2.х, но это является результатом некоего багфикса и не зависит от добавленных модификаторов volatile.
2. Тест бестолковый и зависит от часового пояса и времени там, где он запускается.
Такие дела.
PS. Парочка ссылок:
http://stackoverflow.com/a/4635571/100237
http://beautynbits.blogspot.com/2012/11/the-cost-of-volatile.html
https://dl.dropboxusercontent.com/u/1980587/joda-perf-test.7z (исходник теста и jar'ы)
>>У интела чтение довольно дешевое, запись немного дороже.
На чтении двухкратная разница.
Тем не менее, если немного модифицировать тест:
То легко заметить что volatile-версия медленее в 2-2.4 раза (i5, j7 -server =2.4 | j6 -client =2), чем обычная. Что тоже ощутимо - потеря половины скорости на ровном месте.
Какой именно тест?
>>Запись же я вобще здесь не рассматриваю, т.к. для иммутабельного DateTime запись происходит однажды при инициализации
Это правильно. Вот у нас есть система где надо периодически получать объект таймстампа с текущим временем, то есть генерировать такие объекты с большой частотой. Запись рассматривать нет нужды - надо подгонять результаты под свои слова.
Тест из багтрекера.
>Вот у нас есть система где надо периодически получать объект таймстампа с текущим временем, то есть генерировать такие объекты с большой частотой.
Конкретно речь шла о тесте, на основе которого были сделаны выводы о 15х разнице. Да и если сравнить создание объекта (плюс учесть будущие затраты на GC) и запись volatile, что будет медленнее?
В слоу-версии volatile не более 3%. В старой ощутимей.
Ну, во-первых, я предлагал поставить final вместо volatile.
Запустил. Очень странно. У меня 2.1 regular работает в те же 20 раз медленее чем 2.1 volatile.
Именно так volatile быстрее regulae. Я не путаю. Запускал трижды.
если у тебя программа так часто опрашивает время, что от добавления volatile заметно снизилась производительность, то ты однозначно делаешь что-то неправильно.
>>детский сад. синтетический тест это не тест.
Конечно же.
Безусловно надо написать тест так чтоб, например, бутылочным горлышком было чтение данных с жесткого диска и тестировать HDD, а не код.
Вот тогда получится правильно - как код не пиши - а скорость одинаковая.
А ВДРУГ У ПОЛЬЗОВАТЕЛЯ ЖЕСТКИЙ ДИСК МЕДЛЕННЫЙ?
вот именно про такой детский сад я и говорю. из крайности в крайность.
тест нужно делать реалистичный, целое приложение/систему приложений, с нагрузкой похожей на рабочую.
у нас давече три месяца убили на оптимизацию важной, центральной библиотеки. синтетический тест библиотеки: прирост производительности 100% (в два раза быстрее). тест на копии данных клиентов всего приложения - разница в производительности меньше 1%.
и к слову самое медленое было не чтение с диска (потому что ОС уже оптимизирует это) а другая важная центральная библиотека автор которой архитектор, который к ней никого другого не подпускает.
как можно догадатся, официальная интерпретация результатов теста была весьма смешной. типа все тормозит как и раньше, но так как это (по)менять нельзя, то это значит что приложение уже идеально соптимизировано.
Теперь понятно чего они отказались от joda. Хотя либа в целом годная.
Это не мой "любимый язык". И не близко.
Жава - уродлива во многих аспектах.
В общем, пишем на том что сейчас больше всего востребовано.
Возможно, к некому сожалению, востребованы сейчас сишкоблядские языки, желательно с GC.
И пхп с крестами прельщают еще меньше
Перестанут платить - буду "наезжать" на другие языки.
"Любимый язык" - это обычно у детей. На сосаче таких полно.
Няшных языков нет. Есть только языки, которые позволяют решать конкретный класс задач быстрее и надежней чем другие ;)
Так это ж петух.