Lot of classes vs Just a couple.

Does it impact on performance or stability to how you structure your classes? Right now, I'm up to 5 for an admin plugin...

 

The more classes you have the more laggy it might be but really, it keeps you more organized and so I would advise having more.

 

I'm more worried on the stability, slightly less worried on performance since the plugin itself is not going to be doing any real time stuff... At least, not yet.

 

I think it's just as stable with more classes, what would you be worried about with more classes?

 

public, private, and static to be specifiec. I'm afraid of screwing up and using the wrong modifier, even though the penalty isn't a lot. It's more of being a perfectionist, I guess.

 

Lol, in that case, do what you think is needed!

 

Another question that is completely offtopic, does setThundering(false) also do setStorm(false), or are they two completely different things that need to be set separately?

 

I think so... I was trying to do something like that and I think it started a storm when I made it thunder because it can't be thundering without a storm...

 

Thanks

 

Y? Normally you create one instance of the object (the class) and use it (like a Listener, a CommandExecutor, ...) but even if you create more instances creating a new instance of a object needs (when the objects constructor is empty) 10 CPU cycles. Given the fact that a 3 GHz CPU has 3000000 cycles/seconds I don't think you will get any lag.

 

That was another thought I just had. Why am I worrying about performance when typical servers run on 3 Ghz CPU's nowadays.

 

Isn't 3GHz equal to 3000000000 cycles/second? You have 3Hz, 3.000KHz, 3.000000MHz, then 3.000000000GHz.

 

There is a lot more involved in allocating new objects than just 10 cycles. Every object you allocate will eventually have to be collected as garbage. Always do allocations as rarely as possible. You don't want to be allocating a bunch of objects every tick or anything... even if the affect on performance is small, you don't want to be the straw that breaks the camel's back.

 

I think you're right. I just googled (lazy).

Source/proove? We talk about empty constructors hee, don't forget that!

Do you know how the GC works? It loops through all instances, then copies all still used to a new location and remove the old RAM block (with all no longer needed instances in it). So in fact long-living objects mean more work for the GC than short-living ones as they have to be copied in every GC run.

 

Micro optimization much?

Also use as many classes as you need to break down a problem. A 1k line class is extremely hard to reason about.

 

I didn't mean that allocating an object (with an empty constructor) takes more than 10 clock cycles, I meant that there is the additional cost of GC which isn't included in that.

...except the GC doesn't have to run as often on a program with fewer allocations.

Once an object has survived a few rounds of minor GC, it won't be looked at until a major GC. If you have short-lived objects, they will be looked at every minor GC (making the minor GC take longer).

 

Minecraft itself has over 1000000 intances of different objects (just measured that number on a empty server). Do you really think a plugin will change that number dramatically?

A minor GC vs. a major GC? Well, iirc minor GC doesn't reduce performance for the application anyway.

(Source: http://javarevisited.blogspot.de/2011/04/garbage-collection-in-java.html )

(Source: http://blog.dynatrace.com/2011/03/24/the-impact-of-garbage-collection-on-java-performance/ )

Could it be that your information is a bit out of date? Java tunes more and more for short-living objects with every release since (iirc) Java 1.4