Рейтинг темы:
  • 0 Голос(ов) - 0 в среднем
  • 1
  • 2
  • 3
  • 4
  • 5
Core
#21
lin Написал:"HashMap" проиграет "ConcurrentHashMap" - так как будет эффективнее с большим количеством хранимых данных и операций доступа к ним.

Нет. ConcurrentHashMap ни при каких обстоятельствах не будет быстрее HashMap. Вообще никак.
Ответ
#22
lin Написал:Пардон Smile
Я думал вы про другое, а вы дали исходы с SDK.
На сколько я понял, автор имел ввиду "ConcurrentHashMap или CopyOnWriteArrayList" и грузить конфиги в один объект, без нагрузки с Properties, так как в нем используются устаревшие расширения коллекций "Hashtable" которые синхронизируются по этому производительность уменьшается, так как в данной области будут одновременные обращения.
В многопоточности "Hashtable" проиграет в скорости и производительности в целом.
"HashMap" проиграет "ConcurrentHashMap" - так как будет эффективнее с большим количеством хранимых данных и операций доступа к ним.

Ну в 8й версии они неплохо так подпилили HashMap, поэтому скорость работы при больших коллекциях сильно увеличилась, по сравнению с 7й джавой. Плюс у нас теперь есть parallelStream Wink
Hashtable не только из-за синхронизации такой тормознутый, он еще и сортирует все элементы корейским способом.

abstract

Добавлено через 1 минуту
GabberBaby Написал:Нет. ConcurrentHashMap ни при каких обстоятельствах не будет быстрее HashMap. Вообще никак.

Раньше таки был быстрее. В 8й не знаю, надо делать микро-бенчмарки, да и то, они не показатель на лайве.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ
#23
GabberBaby Написал:Нет. ConcurrentHashMap ни при каких обстоятельствах не будет быстрее HashMap. Вообще никак.
Ошибаетесь, а как же "параллелизм", к тому же ее сейчас еще с большим уклоном сделали под параллельные приложения и даже рекомендовано сейчас использовать именно "ConcurentHashMap" для более высокой производительности.

Добавлено через 4 минуты
Pointer*Rage Написал:
abstract
Хорошая идея... Smile
Ну черкани, если что будет)
Интересно так-то.
Ответ
#24
lin Написал:Ошибаетесь, а как же "параллелизм", к тому же ее сейчас еще с большим уклоном сделали под параллельные приложения и даже рекомендовано сейчас использовать именно "ConcurentHashMap" для более высокой производительности.

Ты серьезно ? Параллелить взятие ОДНОГО элемента с мапы ? Ну ок, куда мне до таких гениев. Я же обычный говнарь, который ничего не смыслит в явке.

Pointer*Rage Написал:Раньше таки был быстрее. В 8й не знаю, надо делать микро-бенчмарки, да и то, они не показатель на лайве.

Ты смотрел очень херовые бенчмарки. В хэшмапе просто по хэшу вытаскивается значение. В конкуррентХэшМапе полюбому есть хоть и маленькая, но блокировка при гете, и пускай хотспот хоть обосрется не сможет он сделать перфоманс этих мап одинаковыми.
Ответ
#25
GabberBaby Написал:Ты серьезно ? Параллелить взятие ОДНОГО элемента с мапы ? Ну ок, куда мне до таких гениев. Я же обычный говнарь, который ничего не смыслит в явке.
Что мешает использовать parallelStream для одного гета? Не Erlang конечно, но все же.


GabberBaby Написал:Ты смотрел очень херовые бенчмарки. В хэшмапе просто по хэшу вытаскивается значение. В конкуррентХэшМапе полюбому есть хоть и маленькая, но блокировка при гете, и пускай хотспот хоть обосрется не сможет он сделать перфоманс этих мап одинаковыми.
Я не имею привычку верить на слово бенчам. Частенько я их сам пишу. Из-за кривоты получения хеша в HashMap, она залипала на больших коллекциях, в отличие, от ее конкурентной версии. Плюс можешь посмотреть сорц конкурентной версии, она основана на CAS, что будет быстрее таки, чем гетинг значения из обычной HashMap в многопоточной среде (тем более с syncronized)
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ
#26
Pointer*Rage Написал:Что мешает использовать parallelStream для одного гета? Не Erlang конечно, но все же.

Хотя бы то, что создание стрима создаст больший оверхед, чем прямой вызов гета.

Pointer*Rage Написал:Я не имею привычку верить на слово бенчам. Частенько я их сам пишу. Из-за кривоты получения хеша в HashMap, она залипала на больших коллекциях, в отличие, от ее конкурентной версии. Плюс можешь посмотреть сорц конкурентной версии, она основана на CAS, что будет быстрее таки, чем гетинг значения из обычной HashMap в многопоточной среде (тем более с syncronized)

Если заполнять хэшмапу только при старте программы, а потом только дергать из нее, то никакая синхронизация не нужна будет. Также в явке 7 апдейт 40 получение хэша в хэшмапе и конкуррентхэшмапе почти ничем не отличается. Возможно в более старых версиях коллизии действительно очень сильно портили производительность мапы, но к серверам л2 это уже не имеет никакого отношения.
Ответ
#27
Мне вот что пришло в голову, что-то как-то так делать, на сколько это будет эффективно я не знаю...
config.properties:
PHP код:
<?php 
#Config types:
boolean-BOOL=false
string
-STR=Name
PHP код:
<?php 
public class Config<Type> {

private static
Map<String, Object> config = new ConcurrentHashMap<>();
private static
String file = "C:\\config.properties";

public static
void main(String[] args) throws IOException {
final
Properties load = new Properties();
load.load(new FileInputStream(Config.file));
for (final
Entry<Object, Object> entry : load.entrySet()) {
final
String[] str = ((String) entry.getKey()).split("-");
if (
2 == str.length) {
switch (
str[0]) {
case
"string":
Config.config.put(str[1], String.valueOf(entry.getValue()));
break;
case
"boolean":
Config.config.put(str[1], Boolean.parseBoolean(String.valueOf(entry.getValue())));
break;
}
}
}
//Вывод:
System.out.println(Config.get("STR")); // String - Name
System.out.println(Config.get("BOOL")); // Boolean - false
}

public static <
Type> Type get(final String key) {
return (
Type) Config.config.get(key);
}
}
Но было бы очень удобно...
PHP код:
<?php 
if("Name".equals(Config.get("STR"))) {
System.out.println(Config.get("STR")); // Name
}
if(
Config.get("BOOL")) {
System.out.println(Config.get("BOOL")); // true
}
Ответ
#28
По теме, <settings exitOnDeath="true" buffRepeat="true" affected="playable"/> параметры зоны
<skill applyEnter="4243,1" removeExit="4243"/> ну и наш баф, который снимает hp.
Ответ
#29
Cywka! Написал:По теме, <settings exitOnDeath="true" buffRepeat="true" affected="playable"/> параметры зоны
<skill applyEnter="4243,1" removeExit="4243"/> ну и наш баф, который снимает hp.
Где вы это на interlude видели?
Ответ
#30
lin Написал:Мне вот что пришло в голову, что-то как-то так делать, на сколько это будет эффективно я не знаю...
config.properties:
PHP код:
<?php 
#Config types:
boolean-BOOL=false
string
-STR=Name
PHP код:
<?php 
public class Config<Type> {

private static
Map<String, Object> config = new ConcurrentHashMap<>();
private static
String file = "C:\\config.properties";

public static
void main(String[] args) throws IOException {
final
Properties load = new Properties();
load.load(new FileInputStream(Config.file));
for (final
Entry<Object, Object> entry : load.entrySet()) {
final
String[] str = ((String) entry.getKey()).split("-");
if (
2 == str.length) {
switch (
str[0]) {
case
"string":
Config.config.put(str[1], String.valueOf(entry.getValue()));
break;
case
"boolean":
Config.config.put(str[1], Boolean.parseBoolean(String.valueOf(entry.getValue())));
break;
}
}
}
//Вывод:
System.out.println(Config.get("STR")); // String - Name
System.out.println(Config.get("BOOL")); // Boolean - false
}

public static <
Type> Type get(final String key) {
return (
Type) Config.config.get(key);
}
}
Но было бы очень удобно...
PHP код:
<?php 
if("Name".equals(Config.get("STR"))) {
System.out.println(Config.get("STR")); // Name
}
if(
Config.get("BOOL")) {
System.out.println(Config.get("BOOL")); // true
}

Как по мне, удобнее сканить класс и сразу уже смотреть по типу поля, во что конвертить стринговое значение.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ


Возможно похожие темы ...
Тема Автор Ответы Просмотры Последний пост
  C3 Win7 - Win10 Core.dll WhiteO 5 2,219 01-19-2016, 10:15 AM
Последний пост: feiteng

Перейти к форуму:


Пользователи, просматривающие эту тему: 1 Гость(ей)