Libbulletjme.so chashed after application destroy,

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.?

  1. The finalization thread was terminated due to the fact that the number of variables for cleaning was full.

  2. 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

http://i.imgur.com/hWp6X2P.png

1 Like

Could we please stop all this! It doesnā€™t lead to anything and just annoys people :weary:

1 Like

ā€¦ you might want to go back and read that again.

2 Likes