Board index FlightGear Release candidates 3.0

3.0.0 MacOS first impressions

This is the archive of topics about the 3.0 release candidates.

Re: 3.0.0 MacOS first impressions

Postby someguy » Fri Jan 31, 2014 3:06 pm

Random trees set to 2.2, weather set to "Fair," random objects off, urban shader one notch up from disabled. The frame rate was 7-15 fps, depending on what scenery filled the windscreen.

Could a memory leak come from the particular aircraft in use? I've flown other models for over an hour without incident. OTOH, a year ago I had to delete the C172 from my hangar because its presence in MP would drop my frame rate to unflyable levels, like the 777 and other overly-complex models. Since 2.12 it's much more tolerable (airliners are still a no-go).
User avatar
someguy
 
Posts: 1650
Joined: Tue Nov 25, 2008 5:54 am
Location: USA
Version: 2019.1.1
OS: Mac OS X 10.11.6

Re: 3.0.0 MacOS first impressions

Postby zakalawe » Fri Jan 31, 2014 10:29 pm

If it's aircraft specific that is very strange. There's a few things that spring to mind; the flight recorder, except it hasn't changed in some releases - but the C172 has a custom config.

Another possibility would be if some instrument or feature we're using the in C172 burns memory - eg tool tips / canvas. All of these options seem unlikely - if tool tips leaked a megabyte per tooltip shown, you would still need to see thousands to cause a memory shortage.

It's very odd.
zakalawe
 
Posts: 1257
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: 3.0.0 MacOS first impressions

Postby Hooray » Fri Jan 31, 2014 10:43 pm

zakalawe wrote in Fri Jan 31, 2014 10:29 pm:Another possibility would be if some instrument or feature we're using the in C172 burns memory - eg tool tips / canvas. All of these options seem unlikely - if tool tips leaked a megabyte per tooltip shown, you would still need to see thousands to cause a memory shortage.

It's very odd.


agreed, I once talked with Stuart and TheTom about also adding details about the amount of physical RAM vs. swap usage, too - having these things available in FG, would make troubleshooting around here quite a bit easier, and would also allow us to do feature-scaling, I provided a patch for this for a Linux implementation back then, and we could probably extend this for all main OS (win, mac, linux): viewtopic.php?f=5&t=16083&p=165168#p164936

As can be seen, we specifically talked about subsystem-specific RAM usage tracking (random buildings, canvas, autopilot, replay/flight recorder etc) -analogous to ThorstenB's system monitor, just with a focus on RAM (memory).

Possibly via some custom smart pointer implementation that overloads new/delete - the main issue being that we really need a way to track memory usage per subsystem, so that we can identify "rogue" features - either to fix them, or to provide hooks for feature-scaling purposes.

For Nasal space, we pretty much have a working solution that could help us identify scripts that are causing lots of new naRefs or temporaries. But C++ code is a different beast, and as can be seen in many discussions here - we have quite a few people with >= 8gb of RAM seeing crashes on 64 bit OS due to "out of RAM" errors.

There's also many other examples for this, such as the v2 scenery eating up tons of RAM without anybody noticing, until the atlas developer pointed this out: viewtopic.php?f=5&t=21498&p=195610&hilit=#p195610

So for post 3.0, we should probably investigate how to track RAM per subsystem/feature and provide some "live" stats.

EDIT: http://wiki.flightgear.org/Subsystem-le ... FlightGear
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12173
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to 3.0

Who is online

Users browsing this forum: No registered users and 1 guest