Вопрос по Джаве

Вопрос по Джаве

А как можно убыстрить занесение данных в HashMap
со string ключем ? TreeMap пробовал -- еще хуже.

Где там bottleneck ?

Ввод -- невырожденный.

Вычисление hash функции занимает незначительное
время, я проверял.

Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.

Много коллизий происходит ? А как это проверить, и что можно
сделать ?

Миша

Re: Вопрос по Джаве


"Mikhail Kimmelman" <mikhail.kimmelman@gmail.com> wrote in message
news:fts6u0$10a7$1@mamba.crocodile.org...

А как можно убыстрить занесение данных в HashMap
со string ключем ? TreeMap пробовал -- еще хуже.

Где там bottleneck ?

Ввод -- невырожденный.

Вычисление hash функции занимает незначительное
время, я проверял.

Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.


Можно еще дать loadfactor, когда не хочется сильно расходовать память


Много коллизий происходит ? А как это проверить, и что можно
сделать ?


Попробовать LinkedHashMap ну или написать свой или hashcode или полную
реализацию.


Re: Вопрос по Джаве

"???????, ??????? (???????)" <javaarchitect@msn.com> wrote in message
news:fts7n8$10sa$1@mamba.crocodile.org...



Где там bottleneck ?

Ввод -- невырожденный.

Вычисление hash функции занимает незначительное
время, я проверял.

Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.


Можно еще дать loadfactor, когда не хочется сильно расходовать память


Меня скорость интересует. А как он поможет ?



Много коллизий происходит ? А как это проверить, и что можно
сделать ?


Попробовать LinkedHashMap


А чем он лучше в этом смысле ?


ну или написать свой или hashcode или полную реализацию.


Миша

Re: Вопрос по Джаве


"Mikhail Kimmelman" <mikhail.kimmelman@gmail.com> wrote in message
news:fts81d$115r$1@mamba.crocodile.org...

"???????, ??????? (???????)" <javaarchitect@msn.com> wrote in message
news:fts7n8$10sa$1@mamba.crocodile.org...



Где там bottleneck ?

Ввод -- невырожденный.

Вычисление hash функции занимает незначительное
время, я проверял.

Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.


Можно еще дать loadfactor, когда не хочется сильно расходовать память


Меня скорость интересует. А как он поможет ?


Не знаю, Сан везде пользует посмотрите в исходниках.



Много коллизий происходит ? А как это проверить, и что можно
сделать ?


Попробовать LinkedHashMap


А чем он лучше в этом смысле ?


Ну если вы думаете что в случае колизий он ползает в поисказ свободной
ячейки, до здесь просто вставляется (но тратится другое время)


ну или написать свой или hashcode или полную реализацию.


Миша



Re: Вопрос по Джаве

"Mikhail Kimmelman" <mikhail.kimmelman@gmail.com> wrote:





Можно еще дать loadfactor, когда не хочется сильно расходовать память


Меня скорость интересует. А как он поможет ?



А ты уверен, что проблема именно в HashMap, а не в, скажем,
создании стрингов? Если в Джаве строки также неизменяемы
как в .NET (а они похоже именно такие), то любая операция
(скажем, взять подстроку или сложить две строки) приводит
к созданию нового объекта и, соотвтетсвенно, копированию
информации. Если строк и/или операций много, это может
отнимать довольно много времени.

А вообще - пrофайлер, пrофайлер и еще раз пrофайлер,
как завещал великий Ленин. Впрочем, как и чем профайлят
Джаву я не в курсе.

Иван

Re: Вопрос по Джаве

"???????, ??????? (???????)" <javaarchitect@msn.com> wrote in message
news:fts889$119k$1@mamba.crocodile.org...





Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.


Можно еще дать loadfactor, когда не хочется сильно расходовать память


Меня скорость интересует. А как он поможет ?


Не знаю,


А что ж тогда советуете ?


Сан везде пользует посмотрите в исходниках.





Попробовать LinkedHashMap


А чем он лучше в этом смысле ?


Ну если вы думаете что в случае колизий он ползает
в поисказ свободной ячейки, до здесь просто вставляется


Это как ?


(но тратится другое время)


Миша

Re: Вопрос по Джаве

"Ivan Krivyakov" <i.van@verizon.net> wrote in message
news:fts8ha$11hc$1@mamba.crocodile.org...


А ты уверен, что проблема именно в HashMap, а не в, скажем,
создании стрингов? Если в Джаве строки также неизменяемы
как в .NET (а они похоже именно такие), то любая операция
(скажем, взять подстроку или сложить две строки) приводит
к созданию нового объекта и, соотвтетсвенно, копированию
информации. Если строк и/или операций много, это может
отнимать довольно много времени.


Строки в джаве immutable, но вроде не в них дело.
Впрочем, в джаве есть и mutable строки,
их-то я на всякий случай и использую.

Мне непонятно, почему вставка в hash map занимает больше
времени, чем добавление в список, хотя вроде вычислением
hash-функции можно пренебречь, и capacity у этого hash map'а
достаточная. Коллизии ? Короче, отупел я совсем.

Миша

Re: Вопрос по Джаве

Mikhail Kimmelman wrote:

Строки в джаве immutable, но вроде не в них дело.
Впрочем, в джаве есть и mutable строки,
их-то я на всякий случай и использую.


Вот в этом mutable и собака.

Ваши mutable строки - это StrungBuffer, так? У StringBuffer hashCode()
не свой, а от Object, в котором он native. native hashCode()
использовать не надо. Никогда. Программа внизу иллюстрирует это. Первые
два hash, которые для разных объектов одинакового содержания
различаются, хотя должны совпадать. Второй и третий hash - для одного
объекта, до и после модификации - совпадают, хотя должны различаться.

Ставьте ключами обычные строки, которые java.lang.String, - и все пройдет.
--
Олег


public class Sb
{
public static void main(String[] args)
{
StringBuffer sb1 = new StringBuffer("x");
System.out.println(sb1 + " " + sb1.hashCode());
StringBuffer sb2 = new StringBuffer("x");
System.out.println(sb2 + " " + sb2.hashCode());
sb2.append("y");
System.out.println(sb2 + " " + sb2.hashCode());
}
}


Re: Вопрос по Джаве

Oleg P <helg@bark.kiev.ua> wrote:

Mikhail Kimmelman wrote:

Строки в джаве immutable, но вроде не в них дело.
Впрочем, в джаве есть и mutable строки,
их-то я на всякий случай и использую.


Вот в этом mutable и собака.

Ваши mutable строки - это StrungBuffer, так? У StringBuffer hashCode()
не свой, а от Object, в котором он native. native hashCode()
использовать не надо. Никогда. Программа внизу иллюстрирует это. Первые
два hash, которые для разных объектов одинакового содержания
различаются, хотя должны совпадать. Второй и третий hash - для одного
объекта, до и после модификации - совпадают, хотя должны различаться.

Ставьте ключами обычные строки, которые java.lang.String, - и все пройдет.


и вы это называете языком для программирования серьезных систем?!


--
Олег


public class Sb
{
public static void main(String[] args)
{
StringBuffer sb1 = new StringBuffer("x");
System.out.println(sb1 + " " + sb1.hashCode());
StringBuffer sb2 = new StringBuffer("x");
System.out.println(sb2 + " " + sb2.hashCode());
sb2.append("y");
System.out.println(sb2 + " " + sb2.hashCode());
}
}



Re: Вопрос по Джаве


"Mikhail Kimmelman" <mikhail.kimmelman@gmail.com> wrote in message
news:fttq5v$2bfm$1@mamba.crocodile.org...

"???????, ??????? (???????)" <javaarchitect@msn.com> wrote in message
news:fts889$119k$1@mamba.crocodile.org...





Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.


Можно еще дать loadfactor, когда не хочется сильно расходовать память


Меня скорость интересует. А как он поможет ?


Не знаю,


А что ж тогда советуете ?


Сан везде пользует посмотрите в исходниках.





Попробовать LinkedHashMap


А чем он лучше в этом смысле ?


Ну если вы думаете что в случае колизий он ползает
в поисказ свободной ячейки, до здесь просто вставляется


Это как ?

Смотрите исходники, они довольно хорошо комментированны.




(но тратится другое время)


Миша



Re: Вопрос по Джаве

"Oleg P" <helg@bark.kiev.ua> wrote in message
news:i2cad5xko3.ln2@divgrad.com...


Ваши mutable строки - это StrungBuffer, так? У StringBuffer hashCode() не
свой, а от Object, в котором он native. native hashCode() использовать не
надо. Никогда. Программа внизу иллюстрирует это. Первые два hash, которые
для разных объектов одинакового содержания различаются, хотя должны
совпадать. Второй и третий hash - для одного объекта, до и после
модификации - совпадают, хотя должны различаться.

Ставьте ключами обычные строки, которые java.lang.String, - и все пройдет.


Спасибо большое за подробные раз'яснения.

Я кстати не знал, что у StringBuffer native hashCode().
Но на самом деле использую в качестве ключа именно String.

И еще, я качестве mutable string'а я использую StringBuilder,
а не StringBuffer, в котором в отличии от последнего
нет синхронизации, которая мне не нужна.

Но я вдруг понял, что на самом деле у меня не map, а multimap,
т.е. у меня несколько значений с одним ключом бывает.
И поэтому используется HashMap<String, List<String>>

Миша

Re: Вопрос по Джаве

Mikhail Kimmelman wrote:


И еще, я качестве mutable string'а я использую StringBuilder,
а не StringBuffer, в котором в отличии от последнего
нет синхронизации, которая мне не нужна.

Но я вдруг понял, что на самом деле у меня не map, а multimap,
т.е. у меня несколько значений с одним ключом бывает.
И поэтому используется HashMap<String, List<String>>


Еще ты конечно же знаешь про тот загадочный встроенный в сановскую JVM profiler,
который зовется странными полудокументированными ключами программе "java" ? И
про доступ к исходникам тоже?

--

Sol Windborn

Re: Вопрос по Джаве


"Sol Windborn" <root@earth.solarsystem.milkyway.universe> wrote in message
news:ftuqfv$h44$2@ddt.demos.su...



И еще, я качестве mutable string'а я использую StringBuilder,
а не StringBuffer, в котором в отличии от последнего
нет синхронизации, которая мне не нужна.

Но я вдруг понял, что на самом деле у меня не map, а multimap,
т.е. у меня несколько значений с одним ключом бывает.
И поэтому используется HashMap<String, List<String>>


Еще ты конечно же знаешь про тот загадочный встроенный
в сановскую JVM profiler, который зовется странными
полудокументированными ключами программе "java" ? И про доступ к
исходникам тоже?


Ну да, но профайлить было лень, т.к. казалось,
что я и так знаю, что происходит.

Но надо будет попробовать.

Миша

Re: Вопрос по Джаве

On Apr 13, 9:49 am, "Mikhail Kimmelman" <mikhail.kimmel...@gmail.com>
wrote:


А как можно убыстрить занесение данных в HashMap
со string ключем ?


Третье Правило Оптимизации. Если первые два не помогли, конечно.

Kit.

Re: Вопрос по Джаве

Mikhail Kimmelman wrote:

А как можно убыстрить занесение данных в HashMap
со string ключем ? TreeMap пробовал -- еще хуже.

Где там bottleneck ?


А у них там было множество вариантов этих мап, с разной степенью синхронизации.
Самый древний вариант - полностью синхронизированный, который поэтому получился
медленным. К которому они потом добавили вариант совсем без синхронизации.
К которым потом добавили варианты с более хитрой поддержкой параллельности.
Я не уверен, как кого из них зовут, так что поинтересуйтесь этим вопросом.

-СБ


Ввод -- невырожденный.

Вычисление hash функции занимает незначительное
время, я проверял.

Начальное capacity задал вроде нормальное. Дальнейшее
его увелечение никакого эффекта не дает.

Много коллизий происходит ? А как это проверить, и что можно
сделать ?

Миша

Re: Вопрос по Джаве

Sol Windborn wrote:

Mikhail Kimmelman wrote:


И еще, я качестве mutable string'а я использую StringBuilder,
а не StringBuffer, в котором в отличии от последнего
нет синхронизации, которая мне не нужна.

Но я вдруг понял, что на самом деле у меня не map, а multimap,
т.е. у меня несколько значений с одним ключом бывает.
И поэтому используется HashMap<String, List<String>>


Еще ты конечно же знаешь про тот загадочный встроенный в сановскую JVM
profiler, который зовется странными полудокументированными ключами
программе "java" ? И про доступ к исходникам тоже?


Не знаю как сейчас, а раньше jode замечательно все декомпилировал.

-СБ

Re: Вопрос по Джаве

"Sergey Babkin" <sab123@hotmail.com> wrote in message
news:58acd5-pq.ln1@news.russian-z1.org...


А у них там было множество вариантов этих мап, с разной степенью
синхронизации.
Самый древний вариант - полностью синхронизированный, который поэтому
получился
медленным. К которому они потом добавили вариант совсем без синхронизации.
К которым потом добавили варианты с более хитрой поддержкой
параллельности.
Я не уверен, как кого из них зовут, так что поинтересуйтесь этим вопросом.


Да я их вроде и так помню.
Синхронизированным Hashtable'ом никто не пользуется.
Все пользуются HashMap'ом

Миша

Re: Вопрос по Джаве

"Nikita V. Belenki" <fido7@kits.net> wrote in message
news:246689cc-5df2-4b4c-933c-bfc26d742510@a5g2000prg.googlegroups.com...



А как можно убыстрить занесение данных в HashMap
со string ключем ?


Третье Правило Оптимизации. Если первые два не помогли, конечно.


Не знаю такого.

В смысле не оптимизировать без надобности ?
Так я это просто из любопытства.

Миша

Re: Вопрос по Джаве

On Apr 15, 8:47 am, "Mikhail Kimmelman" <mikhail.kimmel...@gmail.com>
wrote:




А как можно убыстрить занесение данных в HashMap
со string ключем ?

Третье Правило Оптимизации. Если первые два не помогли, конечно.

Не знаю такого.
В смысле не оптимизировать без надобности ?
Так я это просто из любопытства.


Rule 1: Don't.
Rule 2: Don't yet.
Rule 3: Use profiler.

Kit.

Re: Вопрос по Джаве

Nikita V. Belenki wrote:





А как можно убыстрить занесение данных в HashMap
со string ключем ?

Третье Правило Оптимизации. Если первые два не помогли, конечно.

Не знаю такого.
В смысле не оптимизировать без надобности ?
Так я это просто из любопытства.


Rule 1: Don't.
Rule 2: Don't yet.
Rule 3: Use profiler.


Попытки оптимизировать слишком рано можно использовать как достаточный признак
плохого программиста (безотносительно к Мише К.)

--

Sol Windborn

Re: Вопрос по Джаве

Sol Windborn wrote:

Nikita V. Belenki wrote:





А как можно убыстрить занесение данных в HashMap
со string ключем ?

Третье Правило Оптимизации. Если первые два не помогли, конечно.

Не знаю такого.
В смысле не оптимизировать без надобности ?
Так я это просто из любопытства.


Rule 1: Don't.
Rule 2: Don't yet.
Rule 3: Use profiler.


Попытки оптимизировать слишком рано можно использовать как
достаточный признак плохого программиста (безотносительно к Мише К.)


А мне кажется, что признаком плохого программиста является попытка увидеть
premature optimization в месте, где речь идет о выборе технологии.