Optimize Java method using the concept of Scopes

Question:

Well some time ago, when I took some J2ME for Mobile classes (almost deceased ✞), where I was introduced to a concept of scope hitherto unknown to me, which would be this:

{
    // cria um novo escopo
}

Where anywhere in a method it is possible to force new scopes. Searching I found some sources and references that could be the article Thinking in Java on the Linuxtopia website and this other question from StackOverflow .

So looking to optimize some features in my Android apps, I thought about refactoring my code to take advantage of this way of managing resources, but I'm not aware if it really makes any difference.

So I present the following example, to contextualize my question:

Example:

Suppose I have a large class that allocates a lot of resources when it starts up:

public class ClasseGrande{

    // ...

    public void alocaMuitosRecursos(){
        // Aqui inicia varios atributos da ClasseGrande()
        // ...
    }

    public String obtemResultado(){
        return "Resultado da classe grande";
    }    
}

And the following 3 usage approaches:

Approach 1 (My current):

// tudo no mesmo scope
public void testScopeMethod1(){
    ClasseGrande classeGrande = new ClasseGrande();
    classeGrande.alocaMuitosRecursos();

    // ... usar a classe grande

    String resultado = classeGrande.obtemResultado();

    // agora não se utiliza mais a classe grande só se manipula seu resultado

    // faz vários processos com o atributo resultado

    // ...

    // termina método, e só aqui todos os recursos são liberados para GC. Certo?
}

Approach 2 (using methods to split scopes):

// utiliza método para trocar de scope
public void testScopeMethod2(){
    String resultado = processaClasseGrande();

    // faz vários processos com o atributo resultado

    // ...

    // termina método, e libera os recursos do método testScopeMethod2
}

private String processaClasseGrande(){
    ClasseGrande classeGrande = new ClasseGrande();
    classeGrande.alocaMuitosRecursos();

    // ... usar a classe grande

    return classeGrande.obtemResultado();

    // aqui a classe grande já é liberada, pois finalizou-se seu escopo de método. Certo?
}

Approach 3 (using sub-scopes within the method itself, right after using the resource):

// com sub scope no método
public void testScopeMethod3(){
    String resultado;
    {
        ClasseGrande classeGrande = new ClasseGrande();
        classeGrande.alocaMuitosRecursos();

        // ... usar a classe grande

        resultado = classeGrande.obtemResultado();
        // aqui a classe grande já é liberada, pois finalizou-se seu escopo. Certo?
    }

    // agora não se utiliza mais a classe grande só se manipula seu resultado

    // faz vários processos com o atributo resultado

    // ...

    // termina método, e libera os recursos do método testScopeMethod, mas a classe grande já foi libera logo após ser utilizada. Certo?
}

Questions:

  • Does it really make a difference in performance? Why?
  • If it makes a difference, do approaches 2 and 3 show performance differences? Where and why?
  • If that makes any sense, would it be good practice to keep this in mind for robust designs, especially mobile devices?

Answer:

Something very important about scope is the time your objects will remain in the heap (Area of ​​memory where the JVM allocates objects).

It is not interesting for an object to remain in memory longer than necessary, so it is important to define the scopes well as it facilitates the work of the Garbage Collector.

So, answering your questions:

Does it really make a difference in performance? Why?

Perhaps. It is very important to make good use of computing resources, especially when we talk about cell phones and gadgets of the type.

Making good use of the concept of scope is only a positive factor in your code, but it's not all. Defining the scope well may not make your program faster, but it will keep it robust and consistent, unlike those programs that get slower and slower at the end of the day, forcing us to reboot it.

If it makes a difference, do approaches 2 and 3 show performance differences? Where and why?

Considering what I said in the first answer and looking at the approaches, no. Looking quickly at the two I don't see much difference between them.

I particularly prefer approach two, as each object will exist during the execution of its respective method.

Approach 3 can be interesting in very large methods that allocate a lot of objects, but I would still consider refactoring.

If that makes any sense, would it be good practice to keep this in mind for robust designs, especially mobile devices?

Yes. If compared to a server, mobile devices are very limited. We always need to keep in mind that an app that consumes a lot of resources consumes a lot of battery, no one will use such an app.

Scroll to Top