Pytanie o optymalizacje

[babciaaaa]

czesc, chcialbym zapytac ktory sposob bedzie bardziej wydajny

1.Pobierac dane prosto z configa:

public void Teleport(Player p, String tp){ 
   if(tp == "spawn"){
      p.teleport(new Location(Bukkit.getWorld(Main.getInst().getConfig().getString("SpawnWorld")), Main.getInst().getConfig().getInt("SpawnX"), Main.getInst().getConfig().getInt("SpawnY"), Main.getInst().getConfig().getInt("SpawnZ")));
   }

2.Korzystac z zmiennych:

public void Teleport(Player p, String tp){
        World w = Bukkit.getWorld(Main.getInst().getConfig().getString("SpawnWorld"));
        int x = Main.getInst().getConfig().getInt("SpawnX");
        int y = Main.getInst().getConfig().getInt("SpawnY");
        int z = Main.getInst().getConfig().getInt("SpawnZ");
        
        if(tp == "spawn"){
            p.teleport(new Location(w, x, y, z));
        }
    }

[damianq20]

najlepiej by było gdybyś te dane wczytał przy starcie pluginu , np do jakichś pól statycznych ba możesz nawet zapisać obiekt Location tak dla wygody

[ZnanyJakoOszust]

Jaki to bedzie plugin to ci odpowiem  

[Viscore]

Rozmawiałem kiedyś na innym forum w sprawie optymalizacji pluginu. Póki nie trzymasz zmiennych w pamięci możesz pisać praktycznie tak jak Ci się podoba, z dowolną liczbą funkcji czy metod. Po prostu musisz nabrać nawyku aby każdej zmiennej, której na pewno nie będziesz w przyszłości używać, a która np po wpisaniu jakiejś komendy i tak się zainicjuje od nowa nadal wartość null (usunąć zmienną). Nie mówię tutaj o zmiennych wewnątrzklasowych tylko publicznych. Dam Ci przykład:

 

Używasz configu YML

Inicjujesz w głównej klasie zmienną public static YamlConfiguration config;

W metodzie onEnable() przypisujesz wartość zmiennej config = this.getConfig();

 

Ta zmienna będzie siedziała w pamięci cały czas podczas działania pluginu, co zmniejsza wydajność. Konfiguracji YAML użyłem tylko jako przykładu dla zmiennej publicznej ! Równie dobrze może to być zmienna typu Integer, Boolean, Tablica czy Mapa.

 

 

 

[babciaaaa]

wielkie dzieki za pomoc.

 

Jaki to bedzie plugin to ci odpowiem

Bedzie to plugin na automatyczne eventy.

[bartzz]

Oba przykłady będą działały tak samo, bo:

• wczytujesz te zmienne w metodzie (akurat W TYM przypadku inna opcja nic nie da, patrz punkt niżej)
• wszystkie zmienne w configu są ładowane automatycznie przy starcie do obiektu przez bukkita, więc robiąc configuration.getInt("my-integer") sięgasz do obiektu.
• tworzysz nową lokalizację przy każdej metodzie, a w czasie działania pluginu wartości z configu się nie zmienią, więc lokalizację możesz od razu wcześniej utworzyć, tak samo to działa ze zmiennymi, niepotrzebnie zapychasz ram.

Ogółem to polecam poczytać https://pl.wikipedia.org/wiki/CamelCase, bo razi w oczy!

A no i warto wspomnieć, że sekwencji znaków nie wolno porównywać poprzez operator '==', tylko przez .equals(Object anObject), bądź .equalsIgnoreCase(String anotherString), ze względu na to, że == porównuje bezpośrednio obiekty czy są takie same, a .equals porównuje ich zawartość.

[GotoFinal]

Oba przykłady będą działały tak samo, bo:

• wczytujesz te zmienne w metodzie (akurat W TYM przypadku inna opcja nic nie da, patrz punkt niżej)
• wszystkie zmienne w configu są ładowane automatycznie przy starcie do obiektu przez bukkita, więc robiąc configuration.getInt("my-integer") sięgasz do obiektu.
• tworzysz nową lokalizację przy każdej metodzie, a w czasie działania pluginu wartości z configu się nie zmienią, więc lokalizację możesz od razu wcześniej utworzyć, tak samo to działa ze zmiennymi, niepotrzebnie zapychasz ram.

Ogółem to polecam poczytać https://pl.wikipedia.org/wiki/CamelCase, bo razi w oczy!

A no i warto wspomnieć, że sekwencji znaków nie wolno porównywać poprzez operator '==', tylko przez .equals(Object anObject), bądź .equalsIgnoreCase(String anotherString), ze względu na to, że == porównuje bezpośrednio obiekty czy są takie same, a .equals porównuje ich zawartość.

Jako że lubię się czepiać:

 

"nie wolno" to złe określenie, czasami używa się == w stringach, bo właśnie oczekuje się tego samego obiektu, bo taka logika, lub wiesz że nie ma innej możliwości, np field.getName() zawsze zwraca wartość z poola, więc porównując stringi z java.lang.reflect.Field.getName można używać ==, (o ile oba stringi są z jakiegoś fielda) i takich sytuacji kilka jest, ale znaczenia to nie ma... bo equals i tak sprawdza też == i dopiero potem porównuje zawartość, więc i tak wtedy używa się equals.

No ale tak to masz rację, OP powinien użyć equals :P