DeclaredBefore 1,759.209 ns
DeclaredInside 2,242.308 ns
if you have 120 thousands lines of code which not optimized - this can turn into a few seconds
1 Like
I hope youāre joking.
1 Like
ā¦ Iām not arguing with results.
Iām arguing that the article you linked disagreeās with what youāre saying as far as design goes.
Youāre suggesting that declaring the variable outside of the loop and reusing it is faster/better than declaring inside a loop. Right?
The article you linked says that variables should have the smallest scope possible and in the example they gave itās shown as declaring the variable INSIDE the loop. Not outside.
Even the second best answer in that article shows that the byte code is identical, but points out that minimizing scope is best.
2 Likes
Your test method is flawed because the byte code will be identical.
2 Likes
Criteria of memory and speed.
The fact that minimizing the scope of change is better - I did not consider this option.
But the speed wins another option.?
-
The finalization thread was terminated due to the fact that the number of variables for cleaning was full.
-
You need to clean up the low-level libraries for reuse. Before the end of the program.
Memory: 190MB used during application operation 90-100MB after cleaning and finishing + finalizer and garbage collector do not break
1 Like
I do not use compilation when starting the server.
There is a compilation on the fly.
f there works byte code optimization is good.
But I think that such things need to be envisaged
1 Like
There is no memory difference between these two:
The fact that you think so is why we are saying you donāt know what you are talking about.
Your performance number differences are because of something else or your microbenchmark is flawed. Itās hard to say which because we canāt see that code or the testing methodology.
The byte code generated by the compiler for those two cases should be virtually the same if not exactly the same.
1 Like
Translation: ādo things an inefficient way for no reason so facts of the rest of the world donāt mean anything to meā
Well, if you are already screwing around with everything else then you are your own source of issues. The java compile will treat both of those loops the same.
1 Like
GC Heap History (10 events):
1 Like
Well could always look at the byte code and compare between the 2 methods.
In the article you linkedā¦ https://stackoverflow.com/a/8878071
Use the commands in there to get the byte code output and compare the results. Itāll show you how the JIT compiles it.
1 Like
Itās like watching a monkey bang on a television and think thatās why the people are moving around āinsideā.
2 Likes
Okay pspeed.
How would you suggest solving the problem at the beginning of the topic with a fatal error?
1 Like
Step 1: use the best practices already given.
If itās still brokenā¦
Step 2: put together a simple test case illustrating the problem.
1 Like
The compiler optimizes the code and turns into a byte code.
Then if we know what kind of behavior it leads to, this will shorten the compilation time.
There must surely be a benefit
1 Like
The compile time between those two pieces of code will be the same.
The byte code between those two pieces of code will be the same.
You are a troll.
2 Likes
Article on IBM this topic
1 Like
Which has nothing to do at all with this discussion.
You canāt just post random links. You have to point out why it supports your argument (hint: it doesnāt)
ā¦else you are just wasting our time and being a troll. Which weāve all pretty much figured out anyway.
Go find some other forum to troll, please.
2 Likes
It tells you why you need to set variables to null
1 Like
Could we please stop all this! It doesnāt lead to anything and just annoys people 
1 Like
ā¦ you might want to go back and read that again.
2 Likes