resolvido Configurações carregadas no onEnable (configs em cache é isso?)

[RUSHyoutuber]

Bom, eu vejo muitos developers falando sobre cache, configurações em cache etc etc....

 

Eu queria saber como faço para o meu plugin não precisar ir até a config.yml toda hora pra pegar uma String ou uma Int...

 

Eu li algumas coisas sobre carregar a config no onEnable() usando esse código:

   public void onEnable() {
	    loadConfig();
	    saveDefaultConfig();
            registrarEventos();}


   public void loadConfig()   {
	     if (getConfig().getString("Spawn.world") != null) {
	       spawn = new Location(getServer().getWorld
	                (getConfig().getString("Spawn.world")), 
	                getConfig().getDouble("Spawn.x"), 
	                getConfig().getDouble("Spawn.y"), 
	                getConfig().getDouble("Spawn.z"), 
	                Float.parseFloat(getConfig().getString("Spawn.yaw")), 
	                Float.parseFloat(getConfig().getString("Spawn.pitch")));
	     }
	   }

Se eu usar esse código eu não preciso mais usar getConfig().getString("spawn") é só usar Main.spawn

 

 

Isso ajuda a otimizar o PL?? Tem alguma maneira melhor de fazer isso?? Estou fazendo do jeito certo?? Isso é deixar a config em cache??

[Marsh, o Lendário]

Cache que eu saíba é um método de otimização exemplo:

String FORMAT = getConfig().getString("Format");

player.sendMessage(FORMAT);

O pessoal do fórum já explicou em um tópico, é bom fazer cache porquê o servidor consome memória desnecessesária
Cache é desse jeito ae (Pelo que explicaram no fórum, se eu estiver errado não bota a culpa em mim.)

[Naghtrion]

acho que estou errado, mas pra mim a config já fica em memoria

porque se você poe uma frase, executa o comando, vai na config altera a frase, volta no server e executa o comando, a frase não mudou.

 

no seu caso pode ser ate melhor, visto que você salvou um objeto, ai é só chamar ele... se não tivesse você teria que ficar criando um novo toda vez em que chamar (não ha diferença aplausível)

[RUSHyoutuber]

Cache que eu saíba é um método de otimização exemplo:

 

String FORMAT = getConfig().getString("Format");

 

player.sendMessage(FORMAT);

 

O pessoal do fórum já explicou em um tópico, é bom fazer cache porquê o servidor consome memória desnecessesária

Cache é desse jeito ae (Pelo que explicaram no fórum, se eu estiver errado não bota a culpa em mim.)

 

é melhor fazer

 

String mm = getconfig().getString("mensagem")

p.sendMessage(mm)

 

ou é melhor

 

p.sendMessage(getConfig.getString("mensagem") 

 

??

acho que estou errado, mas pra mim a config já fica em memoria

porque se você poe uma frase, executa o comando, vai na config altera a frase, volta no server e executa o comando, a frase não mudou.

 

no seu caso pode ser ate melhor, visto que você salvou um objeto, ai é só chamar ele... se não tivesse você teria que ficar criando um novo toda vez em que chamar (não ha diferença aplausível)

 

O meu objetivo é tentar otimizar o plugin o maximo possivel! 

 

Visto que o plugin tem mais de 100 mensagens e configs, é mais vantajoso criar uma classe chamada Config ai colocar lá dentro todas strings e ints ?? Ou é melhor ir dentro de cada classe e colocar String = bla bla dentro da classe mesmo?? 

 

Em uma escala de 0 a 100% o quanto isso afetaria no desempenho? Criar uma classe pra todas as strings, ou criar as strins dentro das classes mesmo ou pegar direto da config?

[Guest Shisui]

Cache que eu saíba é um método de otimização exemplo:

 

String FORMAT = getConfig().getString("Format");

 

player.sendMessage(FORMAT);

 

O pessoal do fórum já explicou em um tópico, é bom fazer cache porquê o servidor consome memória desnecessesária

Cache é desse jeito ae (Pelo que explicaram no fórum, se eu estiver errado não bota a culpa em mim.)

 

Isso não é cache, e se for, não faz sentido já que você usa a string FORMAT e a string FORMAT pega da config

 

 

~~ tópico ~~

 

 

Pelo que sei, cache é meio que assim, exemplo:

 

 

Como você pode ver na print, quando o jogador entra, ele pega a quantia de abates e mortes do SQL e passa pra uma hashmap

 

Já aqui no comando, você pode ver q eu pego o valor da hashmap, ou seja, se não tivesse o cache, eu teria que pegar o valor da hashmap (fazendo outra consulta no sql)

 

 

pra completar, agora, quando o jogador sair do servidor, simplesmente vai salvar na SQL os dados da hashmap

 

 

E quando o jogador matar outro, ele adiciona o novo valor na hashmap e não diretamente no SQL (assim, prevenindo fazer outra consulta no SQL)

 

 

E esse método...

 

 

Eu chamo esse método no onEnable() (caso haja jogadores online) para não deixar a hashmap vazia

e uso isso, para caso o servidor caia e os jogadores não percam os dados da hashmap

 

 

Isso fica no onDisable() pra qualquer urgência, os jogadores serão salvos.

 

ACHO QUE ISSO É CACHE, POSSO ESTAR TOTALMENTE ERRADO!

Editado Fevereiro 16, 2018 por Shisui

[RUSHyoutuber]

 

Isso não é cache, e se for, não faz sentido já que você usa a string FORMAT e a string FORMAT pega da config

 

 

~~ tópico ~~

 

 

Pelo que sei, cache é meio que assim, exemplo:

 

 

Como você pode ver na print, quando o jogador entra, ele pega a quantia de abates e mortes do SQL e passa pra uma hashmap

 

Já aqui no comando, você pode ver q eu pego o valor da hashmap, ou seja, se não tivesse o cache, eu teria que pegar o valor da hashmap (fazendo outra consulta no sql)

 

 

pra completar, agora, quando o jogador sair do servidor, simplesmente vai salvar na SQL os dados da hashmap

 

 

E quando o jogador matar outro, ele adiciona o novo valor na hashmap e não diretamente no SQL (assim, prevenindo fazer outra consulta no SQL)

 

 

E esse método...

 

 

Eu chamo esse método no onEnable() (caso haja jogadores online) para não deixar a hashmap vazia

e uso isso, para caso o servidor caia e os jogadores não percam os dados da hashmap

 

 

Isso fica no onDisable() pra qualquer urgência, os jogadores serão salvos.

 

ACHO QUE ISSO É CACHE, POSSO ESTAR TOTALMENTE ERRADO!

 

 

Isso ai faz bastante sentido! Provavelmente irei fazer isso quando eu começar a criar pls que usem banco de dados...  Obrigado pela explicação!

 

Por enquanto eu só to criando PLs sem banco de dados apenas com Config... então a minha duvida ainda continua...

 

fazer aquela parada de carregar a config no onEnable() muda algo no desempenho?

é melhor criar uma classe com todas as strings das mensagens usadas no plugin ou é criar cada string em sua classe? ou é melhor pegar as strings direto da config?

[DeltaT]

O cache em si ele fica na memoria mas toda vez que vc passa de uma sessão ele criar a parti de um Map<?, ?> Ex: "Players.Configuration.Otimizacao" = 1, nessa parte tem 2 Sessões e 1 uma variável.

 

Cada vez que você pega algo que no codico tenha que colocar "." ele criar uma sessão nova toda vez.

Alem de algumas vezes se vc tenta pega um objeto que é tenha um "serial" e que possa converte para aquele objeto ele cria um novo.

 

Que eu me lembre e isso. Mas já faz tempo que eu não estudo sobre yaml padrão do Bukkit pós eu possuo um próprio sistema de yaml. 

[leonardosc]

Que eu saiba as configurações já ficam carregadas na memória.

 

 

 

Isso não é cache, e se for, não faz sentido já que você usa a string FORMAT e a string FORMAT pega da config

 

 

~~ tópico ~~

 

 

Pelo que sei, cache é meio que assim, exemplo:

 

 

Como você pode ver na print, quando o jogador entra, ele pega a quantia de abates e mortes do SQL e passa pra uma hashmap

 

Já aqui no comando, você pode ver q eu pego o valor da hashmap, ou seja, se não tivesse o cache, eu teria que pegar o valor da hashmap (fazendo outra consulta no sql)

 

 

pra completar, agora, quando o jogador sair do servidor, simplesmente vai salvar na SQL os dados da hashmap

 

 

E quando o jogador matar outro, ele adiciona o novo valor na hashmap e não diretamente no SQL (assim, prevenindo fazer outra consulta no SQL)

 

 

E esse método...

 

 

Eu chamo esse método no onEnable() (caso haja jogadores online) para não deixar a hashmap vazia

e uso isso, para caso o servidor caia e os jogadores não percam os dados da hashmap

 

 

Isso fica no onDisable() pra qualquer urgência, os jogadores serão salvos.

 

ACHO QUE ISSO É CACHE, POSSO ESTAR TOTALMENTE ERRADO!

 

 

E onde você remove o jogador do 'cache' ? Ficar mantendo uma referência para um Player mesmo depois que ele desconecta pode causar memory-leak...

 

Eu recomendo que você remova quando o jogador desconectar. Outra opção é usar WeakHashMap, isso fará com que o GC consiga coletar o objeto Player quando ele não estiver mais sendo utilizado.

 

Ali no PlayerDeathE não deveria ser abates.put(pp, abates.get(pp) + 1); ?

[BananaDePijama]

O Bukkit salva o arquivo config na memória, (não tenho certeza, nunca vi), e quando alguma config é pega de alguma forma, ele salva as informações em uma hashmap<String,String> onde o primeiro valor é o path e o outro é o valor da config...

 

Tem um ponto bom e ruim nisso... O ruim é que usa memória desnecessária as vezes, e o ponto bom é que não precisa percorrer o arquivo sempre que algum path parecido é carregado (Quando alguém faz plugin sem saber muito '-')

 

Mas o certo mesmo é salvar numa classe todas as informações que você quer pegar da config...

Se a config tiver umas 500 váriaveis, vai levar uns nanosegundos a mair pro hashmap ser percorrido...

 

Também não sei se tem alguma opção no bukkit pra descarregar uma config, pra liberar memória

[zAth]

public void onEnable() {

File file = new File(getDataFolder(), "config.yml");

if (!(file.exists())) {

try {

saveResource("config.yml", false);

} catch (Exception ignored) {}

}

saveDefaultConfig();

loadConfig();

registrarEventos();

}

 

 

Editado Fevereiro 16, 2018 por zAth

[RUSHyoutuber]

Então é mais recomendado criar 1 classe pra salvar todas as mensagens e configs do que usar getConfig().getString("")?

 

Isso vai fazer alguma diferença pq tipo a próprio string vai ter que ir até a config pegar a informação '-' 

 

mas eu acho que vou fazer isso pra deixar um pouco mais organizado

 

zAth pra que server isso? verificar se a config.yml existe? se ela existir ai acontece tal coisa se não existir acontece tal?

[Guest Shisui]

 

Que eu saiba as configurações já ficam carregadas na memória.

 

 

 

E onde você remove o jogador do 'cache' ? Ficar mantendo uma referência para um Player mesmo depois que ele desconecta pode causar memory-leak...

 

Eu recomendo que você remova quando o jogador desconectar. Outra opção é usar WeakHashMap, isso fará com que o GC consiga coletar o objeto Player quando ele não estiver mais sendo utilizado.

 

Ali no PlayerDeathE não deveria ser abates.put(pp, abates.get(pp) + 1); ?

 

 

Quando o jogador desconecta, ele não é removido automaticamente de uma arraylist/hashmap ? Caso não, fui tapiado por um ótimo tempo kk

	@EventHandler
	public void PlayerQuiE(PlayerQuitEvent e) {
		
		Player p = e.getPlayer();
		
		int abates = EloListeners.abates.get(p);
		int mortes = EloListeners.mortes.get(p);
		EloSQL.novoValorTabelaInt(p, "Abates", abates);
		EloSQL.novoValorTabelaInt(p, "Mortes", mortes);

		EloListeners.abates.remove(p);
		EloListeners.mortes.remove(p);
		
	}

Sobre o PlayerDeathE, já corrigi, muito obrigado

Vou ver sobre esse WeakHashMap

[Dery]

Todo YML é carregado para uma HashMap<String, Object> ao dar YamlConfiguration.loadConfiguration(File).

 

Ela já fica na memória...

[FilipeNock]

Os cara puxando o SQL toda vez que o player entra e sai do servidor... ou YAML, man quando o servidor iniciar carrega todos os dados da config, exemplo

 

Servidor Inicia:  Carrega todos os dados para um HashMap com o Objeto 

 

Quando o jogador entrar: checa se existe algum Objeto com o UUID dele na HashMap, caso não existir adicione um novo Objeto na HashMap

 

Servidor Desligando: salva todos os dados no YML, SQL

 

Puxar da config toda vez que o player entrar isso vai pesar o servidor

[Guest Shisui]

Os cara puxando o SQL toda vez que o player entra e sai do servidor... ou YAML, man quando o servidor iniciar carrega todos os dados da config, exemplo

 

Servidor Inicia:  Carrega todos os dados para um HashMap com o Objeto 

 

Quando o jogador entrar: checa se existe algum Objeto com o UUID dele na HashMap, caso não existir adicione um novo Objeto na HashMap

 

Servidor Desligando: salva todos os dados no YML, SQL

 

Puxar da config toda vez que o player entrar isso vai pesar o servidor

 

Eu estava pensando em fazer dessa maneira, mais eu tentei um dia (quando era mais iniciante) e deu erro, ai fiquei com receio, vou tentar usar dessa forma que tu falou

[ΔŘŦĦỮŘǤỮƗ]

Eu salvo mensagens em HashMap<String,String> -' faço uma class cujo nome é Mensagem ai coloco Mensagem.add("titulo da mensagem", "mensagem"); e quando quero consultar só Mensagem.get("titulo da mensagem"); o mesmo faço com locais de teleport entre outros... Acho que daria pra fazer com um arquivo .yml um sistema que você faz um stringlist ou algo tipo getString de cada sessão

 

Tipo - 'TITULO;MENSAGEM' (StringList)

E só no get normal uso 'Titulo': 'Mensagem'

[Ygor]

Eu salvo mensagens em HashMap<String,String> -' faço uma class cujo nome é Mensagem ai coloco Mensagem.add("titulo da mensagem", "mensagem"); e quando quero consultar só Mensagem.get("titulo da mensagem"); o mesmo faço com locais de teleport entre outros... Acho que daria pra fazer com um arquivo .yml um sistema que você faz um stringlist ou algo tipo getString de cada sessão

 

Tipo - 'TITULO;MENSAGEM' (StringList)

E só no get normal uso 'Titulo': 'Mensagem'

Perfeito, vou pegar seu método mas vou fazer algumas alterações como exemplo, eu não testei então me corrija se eu estiver errado.

 

Primeiro vamos criar uma HashMap que armaze String e String, já que é para guardar as mensagens..

public static HashMap<String, String> msgs = new HashMap<String, String>();

Logo depois no onEnable você deve criar o arquivo, vou considerar que você está utilizando o padrão config.yml

public void onEnable() {
	saveDefaultConfig();
}

Após salvar nós vamos inserir todas as Strings da config (das mensagens que é o que nos interessa aqui) e também as mensagens quando o plugin ligar, então inserimos isso no onEnable():

for(String all : getConfig().getConfigurationSection("Mensagens").getKeys(false)) {
	msgs.put(all, getConfig().getString("Mensagens." + all));		
}

Pronto, tudo já está salvo na HashMap, para você acessar basta utilizar:

msgs.get(path);

Vale lembrar que minha config está assim:

Mensagens:
  Exemplo1: "Este é um simples teste"
  Exemplo2: "E aí"
  Exemplo3: "Como vai?"

Então você pode alterar e adequar como quiser, alterando também o código.

 

Bom, agora ao invés de ir na config você pegará as Strings da HashMap, por exemplo:

public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
	if(command.getName().equalsIgnoreCase("cache")) {
		sender.sendMessage("§6" + msgs.get("Exemplo1"));
	}
	return false;
}

Bom, no caso aqui será exibido: Este é um simpes teste.

 

Lembrando que não testei então pode estar tudo errado, rs, tomei como base o exemplo que citei aqui.

Espero ter ajudado, até mais.

Editado Fevereiro 16, 2018 por JoaoY

[zDubsCrazy2]

Todo YML é carregado para uma HashMap<String, Object> ao dar YamlConfiguration.loadConfiguration(File).

 

Ela já fica na memória...

Exatamente isso...

 

* Uma dica pra quem tá começando: instale um plugin no Eclipse para decompilar classes, assim você vai vendo como funciona as coisas "por debaixo do pano", inclusive as classes do Bukkit.

[RUSHyoutuber]

Perfeito, vou pegar seu método mas vou fazer algumas alterações como exemplo, eu não testei então me corrija se eu estiver errado.

 

Primeiro vamos criar uma HashMap que armaze String e String, já que é para guardar as mensagens..

public static HashMap<String, String> msgs = new HashMap<String, String>();

Logo depois no onEnable você deve criar o arquivo, vou considerar que você está utilizando o padrão config.yml

public void onEnable() {
	saveDefaultConfig();
}

Após salvar nós vamos inserir todas as Strings da config (das mensagens que é o que nos interessa aqui) e também as mensagens quando o plugin ligar, então inserimos isso no onEnable():

for(String all : getConfig().getConfigurationSection("Mensagens").getKeys(false)) {
	msgs.put(all, getConfig().getString("Mensagens." + all));		
}

Pronto, tudo já está salvo na HashMap, para você acessar basta utilizar:

msgs.get(path);

Vale lembrar que minha config está assim:

Mensagens:
  Exemplo1: "Este é um simples teste"
  Exemplo2: "E aí"
  Exemplo3: "Como vai?"

Então você pode alterar e adequar como quiser, alterando também o código.

 

Bom, agora ao invés de ir na config você pegará as Strings da HashMap, por exemplo:

public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
	if(command.getName().equalsIgnoreCase("cache")) {
		sender.sendMessage("§6" + msgs.get("Exemplo1"));
	}
	return false;
}

Bom, no caso aqui será exibido: Este é um simpes teste.

 

Lembrando que não testei então pode estar tudo errado, rs, tomei como base o exemplo que citei aqui.

Espero ter ajudado, até mais.

 

Então criar essa hashmap é melhor doque pegar direto da config.yml?? Levando em consideração que eu tenho 2 arquivos de configuração 1 deles com mais ou menos 55 e outro com mais ou menos 90. Isso daria "otimizadinha" no plugin?

 

Numa escala de 0 a 100% isso ajuda pelo menos uns 5%?

 

Os caras tinha citado acima que quando o plugin liga já fica salvo em uma hashmap então isso não seria inutil? não entedi oque eles quiserem dizer 

Exatamente isso...

 

* Uma dica pra quem tá começando: instale um plugin no Eclipse para decompilar classes, assim você vai vendo como funciona as coisas "por debaixo do pano", inclusive as classes do Bukkit.

 

 

Eu salvo mensagens em HashMap<String,String> -' faço uma class cujo nome é Mensagem ai coloco Mensagem.add("titulo da mensagem", "mensagem"); e quando quero consultar só Mensagem.get("titulo da mensagem"); o mesmo faço com locais de teleport entre outros... Acho que daria pra fazer com um arquivo .yml um sistema que você faz um stringlist ou algo tipo getString de cada sessão

 

Tipo - 'TITULO;MENSAGEM' (StringList)

E só no get normal uso 'Titulo': 'Mensagem'

 

Eu salvo mensagens em HashMap<String,String> -' faço uma class cujo nome é Mensagem ai coloco Mensagem.add("titulo da mensagem", "mensagem"); e quando quero consultar só Mensagem.get("titulo da mensagem"); o mesmo faço com locais de teleport entre outros... Acho que daria pra fazer com um arquivo .yml um sistema que você faz um stringlist ou algo tipo getString de cada sessão

 

Tipo - 'TITULO;MENSAGEM' (StringList)

E só no get normal uso 'Titulo': 'Mensagem'

 

Os cara puxando o SQL toda vez que o player entra e sai do servidor... ou YAML, man quando o servidor iniciar carrega todos os dados da config, exemplo

 

Servidor Inicia:  Carrega todos os dados para um HashMap com o Objeto 

 

Quando o jogador entrar: checa se existe algum Objeto com o UUID dele na HashMap, caso não existir adicione um novo Objeto na HashMap

 

Servidor Desligando: salva todos os dados no YML, SQL

 

Puxar da config toda vez que o player entrar isso vai pesar o servidor

 

Todo YML é carregado para uma HashMap<String, Object> ao dar YamlConfiguration.loadConfiguration(File).

 

Ela já fica na memória...

 

Obrigado pelas respostas! Se puderem respondam minha pergunta acima!

[Ygor]

Pelo o que pude ler, eles estão dizendo para que você faça um plugin que armazene numa HashMap ao ligar (para que fique salvo quando o plugin liga, óbvio) e não que quando o plugin liga ele já tenha em HashMap armazenado.

Creio que otimize sim, pois você não ficará acessando o YML diretamente, pois os itens estarão na memória do plugin

Por exemplo o que o FilipeNock  disse são instruções do que você deve fazer, não do que está acontecendo.

Editado Fevereiro 16, 2018 por JoaoY

[Arkasher]

Os cara puxando o SQL toda vez que o player entra e sai do servidor... ou YAML, man quando o servidor iniciar carrega todos os dados da config, exemplo

 

Servidor Inicia:  Carrega todos os dados para um HashMap com o Objeto 

 

Quando o jogador entrar: checa se existe algum Objeto com o UUID dele na HashMap, caso não existir adicione um novo Objeto na HashMap

 

Servidor Desligando: salva todos os dados no YML, SQL

 

Puxar da config toda vez que o player entrar isso vai pesar o servidor

Já pensou se tem 10000 players registrados e apenas 100 estão online? Iriam ficar 9900 dados de players que não estão sendo usados, iria consumir uma memória absurda

[RUSHyoutuber]

Pelo o que pude ler, eles estão dizendo para que você faça um plugin que armazene numa HashMap ao ligar (para que fique salvo quando o plugin liga, óbvio) e não que quando o plugin liga ele já tenha em HashMap armazenado.

Creio que otimize sim, pois você não ficará acessando o YML diretamente, pois os itens estarão na memória do plugin

Por exemplo o que o FilipeNock  disse são instruções do que você deve fazer, não do que está acontecendo.

 

Hmmm Ok.

 

O meu plugin já esta em uma fase bem avançada de construção, já fiz uma boa parte dele mas agora vou ter que deixar ele um tempo de lado! Provavelmente irei fazer isso futuramente!

Já pensou se tem 10000 players registrados e apenas 100 estão online? Iriam ficar 9900 dados de players que não estão sendo usados, iria consumir uma memória absurda

 

Então não é recomendando fazer isso com banco de dados tipo Sql? E configs sera que compensa? pelo que eles falaram sim e oque vc acha?

[Ygor]

Hmmm Ok.

 

O meu plugin já esta em uma fase bem avançada de construção, já fiz uma boa parte dele mas agora vou ter que deixar ele um tempo de lado! Provavelmente irei fazer isso futuramente!

 

Então não é recomendando fazer isso com banco de dados tipo Sql? E configs sera que compensa? pelo que eles falaram sim e oque vc acha?

No caso das mensagens não terá problema na minha concepção, mas por exemplo, caso você tenha um arquivo YML (ou até SQL) que registre os jogadores e você deseja selecionar apenas alguns não será necessário esse método, a não ser que você selecione quem entrará na HashMap.

 

Perdão pela intromissão.

[RUSHyoutuber]

No caso das mensagens não terá problema na minha concepção, mas por exemplo, caso você tenha um arquivo YML (ou até SQL) que registre os jogadores e você deseja selecionar apenas alguns não será necessário esse método, a não ser que você selecione quem entrará na HashMap.

 

Perdão pela intromissão.

 

Vlw pelas assim que eu tiver tempo vou fazer essa parada e vou monitorar o desempenho e ver se vale a pena ><

[???]

Não sei como é nas novas versões apartir da 1.8 pois não cheguei a olhar ainda, mas nas versões 1.5.2 até 1.7.x funcionava da seguinte maneira.

 

O YAML do bukkit a cada getConfig() ele recriava toda a estrutura do arquivo, ele não armazenava em algum tipo de CACHE, por este motivo se via muito falar que não era aconselhável utilizar o getConfig sempre que necessário obter um dado do arquivo. 

 

Ao utilizar o getConfig o código para pegar o arquivo, abrir stream, ler, etc, todo era refeito, por este motivo sempre que utilizavam um

p.sendMessage(getConfig().getString("Putiane.Gemido", "grrr"));

Ele faria todo um stream do config.yml para poder pegar o dado da formatação da chave solicitada.

 

Um modo bem legal que se era utilizado para evitar isso é criar uma classe onde ela depende de uma YamlConfiguration para ou sempre que iniciar carregar todos os dados do YAML ou ele obter dados de uma WeakHashMap, caso não exista ele pega da config e coloca na map para futuramente ela só pegar dessa map, fazendo disso um sistema de cache.

 

Seria tipo isso ai embaixo:

public class CacheYaml{
	
	private HashMap<String, Object> map = Maps.newHashMap();
	private YamlConfiguration yaml;
	public CacheYaml(YamlConfiguration yaml){
		this.yaml = yaml;
	}
	
	public String getString(String key, String default){
		if(map.containsKey(key)){
			return (String)map.get(key);
		}
		String value = this.yaml.getString(key, default);
		map.put(key, value);
		return getString(key, default);
	}
}

OBS: Fiz nesse editor de código aqui do fórum, se eu errar algum caractere, bom, tanto faz euheuheuheuheuhe

 

 

Mas é tipo isso ai.

 

 

 

@Edit

Re-observando: Não sei se isso ainda é assim na 1.8, sei que na 1.5.2 até a 1.7.x era assim, eu não lembro de ter analisado a 1.8, se eu analisei, bom, eu não lembro euheuheuhe

Editado Fevereiro 17, 2018 por   ???  

[zDubsCrazy2]

Não sei como é nas novas versões apartir da 1.8 pois não cheguei a olhar ainda, mas nas versões 1.5.2 até 1.7.x funcionava da seguinte maneira.

 

O YAML do bukkit a cada getConfig() ele recriava toda a estrutura do arquivo, ele não armazenava em algum tipo de CACHE, por este motivo se via muito falar que não era aconselhável utilizar o getConfig sempre que necessário obter um dado do arquivo. 

 

Ao utilizar o getConfig o código para pegar o arquivo, abrir stream, ler, etc, todo era refeito, por este motivo sempre que utilizavam um

p.sendMessage(getConfig().getString("Putiane.Gemido", "grrr"));

Ele faria todo um stream do config.yml para poder pegar o dado da formatação da chave solicitada.

 

Um modo bem legal que se era utilizado para evitar isso é criar uma classe onde ela depende de uma YamlConfiguration para ou sempre que iniciar carregar todos os dados do YAML ou ele obter dados de uma WeakHashMap, caso não exista ele pega da config e coloca na map para futuramente ela só pegar dessa map, fazendo disso um sistema de cache.

 

Seria tipo isso ai embaixo:

public class CacheYaml{
	
	private HashMap<String, Object> map = Maps.newHashMap();
	private YamlConfiguration yaml;
	public CacheYaml(YamlConfiguration yaml){
		this.yaml = yaml;
	}
	
	public String getString(String key, String default){
		if(map.containsKey(key)){
			return (String)map.get(key);
		}
		String value = this.yaml.getString(key, default);
		map.put(key, value);
		return getString(key, default);
	}
}

OBS: Fiz nesse editor de código aqui do fórum, se eu errar algum caractere, bom, tanto faz euheuheuheuheuhe

 

 

Mas é tipo isso ai.

 

 

 

@Edit

Re-observando: Não sei se isso ainda é assim na 1.8, sei que na 1.5.2 até a 1.7.x era assim, eu não lembro de ter analisado a 1.8, se eu analisei, bom, eu não lembro euheuheuhe

Na 1.5.2 já não era assim. Desde sempre FileConfiguration tinha um HashMap<String, Object>, que era carregado com o reloadConfig();

 

@TOPIC:

Não precisa fazer alternativas pro cache da config, ele não lê o arquivo todo momento que tu faz getConfig()! Se for pra mensagens, e outras coisas pode usar normal.

 

Onde tu vai usar cache? Quando tiver dados que para obtê-los consuma recursos consideráveis, por exemplo: 

 

- tu salva dados de jogadores em um database

- tu tem um plugin que tem uma classe PlayerProfile com dados de um jogador (os mesmos do db)

- em vários momentos tu precisa manipular esta classe

- em algum momento (quando jogador entrar no server, etc) tu obtém do db e salva o objeto que tu criou na memória (um HashMap, etc)

- a partir daí tu acessa do "cache", sem precisar fazer uma nova requisição pro db e só faz outras para atualizar dados

Editado Fevereiro 18, 2018 por Inlidável

[RUSHyoutuber]

Obrigado a todos pelas muitas respostas!

 

Conclusão: Fazer cache de strings ou booleans não vale a pena! Não vai melhorar em nada o desempenho!

 

Obrigado a todos pelas respostas!

[nOthing]

Sua dúvida foi marcada como [Resolvido] e movido à área de dúvidas resolvidas.


Atenciosamente,
Gamer's Board