open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Fixing Lag: Picking Up Low Hanging Fruit
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 [3]

Author Topic

Samuel Miner
Caldari
Perilous Expedition
Posted - 2010.09.16 03:10:00 - [61]
 

Man I read this stuff and wonder if there is anyone home on that island coding sometimes. Even my little coding projects I spend some time optimizing for the hell of it. Someone is coding for a high demand, heavy load game that is experiencing lag issues, and it never occurs to them to check this stuff out?

The only excuse would have to be really old code right?

CCP Veritas

Posted - 2010.09.16 17:30:00 - [62]
 

Originally by: Andrevv
Seeing as 0.0 combat involves manual cycling anyway, I don't expect this particular optimization to have any impact on fleet fights. Good job regardless :)


I had a look at the code again and wish to issue a correction. This check happens on every module activation or repeat, so it will impact manual cycling just the same.

Originally by: Andrevv
Am I understanding this correctly, that any repeating module, regardless of whether it takes a charge, does a query to check if its charge group is empty?? because that is what the blog is implying... which seems kind of pointless.


Yes, you are understanding correctly. Thankfully, after this change, it's almost certainly cheaper to ask "Is this reloading?" than "Can this have charges? If so, is it reloading?"

Zagdul
Gallente
Clan Shadow Wolf
Fatal Ascension
Posted - 2010.09.19 06:58:00 - [63]
 

Edited by: Zagdul on 19/09/2010 07:12:34


Originally by: Trebor Daehdoow
Originally by: CCP Veritas
Originally by: Trebor Daehdoow
Since this is the case, would it not be a good idea, as several people have suggested, to consider making some common modules passive -- such as Damage/Drone Control Units?


I don't know how much of a win it would be offhand, but I have been keeping an eye on your thread over in the Assembly about it. Very interesting discussion, that.

Zagdul has suggested that you test this during an upcoming mass test; it would seem to me that it would be pretty easy to do a thin-client test and follow it up with a live test if it is promising. Even if it shaves 1/2% off the load, that's a nice little win, and best of all, you can dump all the work on another team! Twisted Evil
On that post, I also listed another bug which caused the "reappearing ships in space"...

If you take 10-20 SB's and launch them at a fleet, lag is unbearable.

You lose control of your client and things such as warping become impossible, even if you're aligned and ready to go.

Try this on ships with enough HP to take the bombs and a few ships without the hp. You'll enjoy what happens to the ships as they VERY VERY slowly blow up... Half your modules start to disappear... then you lose local and all kinds of fun things start happening.

CCP, setup your thin client and launch some bombs at a bunch of battleships. If you can also throw a few broadcasts, you'll replicate some insane lag.

http://fatalascension.com/killboard/?a=kill_detail&kll_id=14014


According to that page, my ship had 99,551 armor hp as well as another 25,000 hull. If you look at the bombs that hit me:

7 Concussion Bombs and 5 scorch.

With resists and the mechanic behind bombs of a different damage type destroying each other, I should not have died. Or at least, I should have been able to warp my ship out which was fully aligned.

However, since the server load was so intense, it didn't calculate the bombs blowing each other up before hitting the fleet thus we lost a few ships on the run.

I was also being repped through this.

Thunder1971
Caldari
NailorTech Industries
RAZOR Alliance
Posted - 2010.09.20 12:42:00 - [64]
 

Getting there step by step.
Every little bit helps, with lots of work ahead.
I'm very happy that decent progress is made on the subject.
TBH one of the bigger challenges of this project...good luck in your future efforts.

Good work team.

Liang Nuren
Posted - 2010.09.20 20:21:00 - [65]
 

Edited by: Liang Nuren on 20/09/2010 20:22:00
Originally by: Samuel Miner
Man I read this stuff and wonder if there is anyone home on that island coding sometimes. Even my little coding projects I spend some time optimizing for the hell of it. Someone is coding for a high demand, heavy load game that is experiencing lag issues, and it never occurs to them to check this stuff out?

The only excuse would have to be really old code right?


There are problems of "scale" and "time requirements" that I think you're missing out on. Frankly, if you spend tons of time optimizing the hell out of all your production code, you're probably not a good programmer. I'd really rather have someone on my team who outputs 90% of the performance quality you do and puts out 500% of the work - because the difference will be that dramatic.

-Liang

Ed: Which isn't to say that there's not times and places to optimize the hell out of something - because there damn sure is. But saying you should optimize the hell out of everything is pretty naive.

ectweak
Amarr
The Clean Up Crew
S E D I T I O N
Posted - 2010.09.21 17:40:00 - [66]
 

Edited by: ectweak on 21/09/2010 17:41:00
Originally by: Lykouleon
CCP Veritas is my new hero

But he needs to learn how to use pie charts. I wants moar pie charts!!!



I can see CCP Veritas' next devblog having a chart similar to this:
http://www.evl.uic.edu/aej/491/pics/week2/piechart.jpg

But all joking aside, I'm a little concerned about the time and effort being put into removing this "lag", when there are such issues as "moveable PLEX" that need to be addressed. a 26 page threadnaught needs to be dealt with! /trolling

all right, enough of that jazz...

I'm happy to see that the "thin" client is getting it's money worth out of it, and all for the fight against lag. It's one enemy we ALL have


Pages: 1 2 [3]

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only