Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 11:43:32



Reply to topic  [ 2 posts ] 
BOOL 
Author Message

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
Quote:
Got fully rid of LL's silly "BOOL" type use in the "llui" library and most "newview" UI element classes in favour of the C++ native "bool" type (this saves 3 bytes per boolean variable since "BOOL" is actually a 32bits integer (a weird, not to say a very stupid choice !!!) instead of a 8bits integer for "bool"; because each UI element contains dozens of such variables and each inventory item is associated with an UI element, this saves mega-bytes of memory for large inventories: around 10Mb saved for only 15000 items in my inventory). Note that the "BOOL" eradication from the Cool VL Viewer started a long time ago (it's part of those "various minor optimizations and code cleanup" items you can see in each release notes) and will continue (yes, I'm going to commit a BOOL genocide !).


Oh wow, you find the most weird things. :lol:

So with 106k inventory, does it save me around 100MB then? :o

Btw. about memory: as suggested I raised the video memory usage to 512MB. This indeed removed the loop-reload issues completely for, but: apparently for each MB video memory SL seems to use the same amount of main memory, too. So in crowded areas I don't get a loop-reloading anymore but an out-of-memory crash. So I have to find a good value for display memory usuage between loop-reloading and crash. >.<


2013-09-29 07:17:08
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Tillie wrote:
Oh wow, you find the most weird things. :lol:
Indeed... Lindens are (for most of them) far from being optimization champions, like most "young" (30-40 years old and younger) coders who never learned to truly optimize code: back in my first coding days (in the early 70s), the most powerful "computers" I coded on had 1Kb of RAM, 4Kb of ROM, and a 1MHz CPU... This *does* make you learn to squeeze *every byte* and *every CPU clock cycle* out of your code. By my standards, most of today's so-called programs are just bunches of inefficient, bloated crappy pieces of code... That's why you need 2GHz multi-core CPUs and 8Gb of RAM today to "run" (more like "crawl") modern OSes and software...

There were even worst things in the original code for the v1 viewers (that Lindens finally learned to take into account in their newer code), such as saved settings variables (AKA debug settings, which are in fact used for far many more purposes than just debugging), that are referenced via strings (meaning that to retrieve the value of a simple boolean from a setting, you must first compare the name of its variable, character per character, with the names of all the variables) and that only "recently" (IIRC, back in Snowglobe days) had their value cached (LLCachedControl) for faster access.

Quote:
So with 106k inventory, does it save me around 100MB then? :o
See by yourself... Compare the memory usage of v1.26.8.29 with v1.26.8.30, for example (in the exact same conditions, of course, i.e. same settings, same UI elements on screen (e.g. same open floaters), same 3D environment, preferably in an empty sim to avoid issues with nearby avatars coming in and out between the two sessions).

Your mileage may vary also depending on the memory allocator in use (the figure I gave was for Linux with jemalloc as the memory allocator): the gain will be different if the memory allocator reserves space on a byte-aligned scheme, like under 32bits Linux without jemalloc or under Windows without tcmalloc (in which case each C++ object will use exactly the amount of memory needed by its member variables) when compared to 16-bytes aligned allocations (jemalloc, tcmalloc, MacOS-X, where the space allocated to each object is rounded up to the nearest 16 multiplier).

Quote:
Btw. about memory: as suggested I raised the video memory usage to 512MB. This indeed removed the loop-reload issues completely for, but: apparently for each MB video memory SL seems to use the same amount of main memory, too. So in crowded areas I don't get a loop-reloading anymore but an out-of-memory crash. So I have to find a good value for display memory usuage between loop-reloading and crash. >.<
Yes, I already explained that countless times on this forum...


2013-09-29 09:54:34
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 22 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.