Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-19 05:05:51



Reply to topic  [ 9 posts ] 
New Cache 
Author Message

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Hello Henri et al.,

is it just me or is that new "simple" cache blazingly fast compared to the old one? :o Or is that possibly an artefact of me taking the opportunity and manually removing the previous cache beforehand? (Unlikely, as I presume it would have discarded the old one anyway.)


Regards,
Lia


2021-03-06 12:53:07
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
I did not notice any "blazing" effect here (under Linux), but admittedly I'm already using a RAM disk for the viewer cache directory...

It however certainly removes code bloat (*) from the viewer and thus speeds up cached asset files read/write.

(*) i.e. a totally useless code, since a VFS brings no advantage whatsoever. I suppose it was initially adopted as a mean to obfuscate cached files and make ripping them "harder" but, as always, security via obscurity is inefficient and ultimately fails to reach its goal.


2021-03-06 13:18:21
Profile WWW

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Linux here as well, with an NVME SSD. Judging from the texture stats overlay, initial write to cache seems to be taking significantly less time now.

Not having ever looked at the code but only the aforementioned stats overlay ... is texture loading handled similarly to web browser caching, i.e. with a modification checking before using cache content? If so, wouldn't that be counterproductive, considering that textures in SL technically can never change?

I always pondered trying to set up a local transparent proxy for SL assets and textures to see how much that might speed things up, but admittedly never did it because lazy. :lol:

Regards,
Lia


2021-03-06 15:07:02
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
This has nothing to do with textures (excepted when uploading them). That cache is used by most assets (animations, sounds, scripts, note-cards, gestures, wearables, meshes, etc) but not for textures used for rendering, which are still held in the textures cache. Other caches are the objects cache (which caches objects parameters for each visited sim) and the inventory cache (which only caches the inventory items tree, but not any asset those items point at).

I did improve a bit textures fetching speed in the former release however, by avoiding the recourse to textures cache locking when the textures console or viewer stats retrieve the number of textures being fetched.

As for using a local proxy, you would probably be disappointed by the result. Better increasing your viewer cache size and/or storing the latter on a RAM disk (which contents is saved on OS shutdown and restored on reboot).

Here is my (SysVinit, i.e. it is /etc/rc.d/init.d/ramdisk for me: not sure how the shitty systemd would handle that on non-sysv-init systems) script for my Linux PCs:
Code:
#!/bin/bash
#
# ramdisk          Start/Stop the ramdisk.
#
# chkconfig: 2345 01 99
# description: starts and stops the RAM-disk, restoring and saving its \
#              contents.

### BEGIN INIT INFO
# Provides: ramdisk
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start:  2 3 4 5
# Default-Stop: $named
# Short-Description: starts ramdisk
# Description: starts and stops the ram-disk, restoring and saving its \
#              contents.
### END INIT INFO

. /etc/rc.d/init.d/functions

BACKUP_FILE="/var/cache/ramdisk-backup.tar"
MOUNT_POINT="/mnt/ramdisk"
LOCK_FILE="/var/lock/subsys/ramdisk"

case "$1" in
   start)
      mkdir -p $MOUNT_POINT
        action "Mounting ramdisk" mount $MOUNT_POINT
      if [ -f $BACKUP_FILE ] ; then
         cd $MOUNT_POINT
         action "Ramdisk contents restoring" tar xf $BACKUP_FILE
      fi
      touch $LOCK_FILE
      ;;
   stop)
      if mount | grep $MOUNT_POINT &>/dev/null ; then
         if [ -d $MOUNT_POINT/tmp ] ; then
            rm -rf $MOUNT_POINT/tmp/*
         fi
         rm -f $BACKUP_FILE &>/dev/null
         cd $MOUNT_POINT
         action "Ramdisk contents saving" tar cf $BACKUP_FILE .
         cd /
         action "Ramdisk unmounting" umount $MOUNT_POINT
      fi
      rm -f $LOCK_FILE
       ;;
   save)
      if mount | grep $MOUNT_POINT &>/dev/null ; then
         rm -f $BACKUP_FILE &>/dev/null
         cd $MOUNT_POINT
         action "Ramdisk contents saving" tar cf $BACKUP_FILE .
      fi
      ;;
   load)
      if mount | grep $MOUNT_POINT &>/dev/null ; then
         if [ -f $BACKUP_FILE ] ; then
            cd $MOUNT_POINT
            action "Ramdisk contents loading" tar xf $BACKUP_FILE
         fi
      fi
      ;;
   *)
      gprintf "Usage: %s {start|stop|save|load}\n" "$0"
      exit 2
esac

exit $?

And in /etc/fstab I got the following entry for the RAM disk (here set for 12Gb max for a 64Gb RAM system):
Code:
none         /mnt/ramdisk      tmpfs      noauto,size=12G,nodev,lazytime,noatime   0 0

Once you enabled and started the ramdisk service (e.g. for sysv-init: chkconfig --add ramdisk;service ramdisk start) you can move cache_coolvlviewer/ from ~/.secondlife/ to the RAM disk and replace it with in ~/.secondlife with a link to it:
Code:
mkdir /mnt/ramdisk/$USER
cd ~/.secondlife
mv -f cache_coolvlviewer /mnt/ramdisk/$USER/
ln -s /mnt/ramdisk/$USER/cache_coolvlviewer

From now on, the viewer will use the RAM disk automatically, and the latter will automatically be saved/restored on reboots.

Another advantage of using a RAM disk for the viewer cache is that it spares many writes on your SSD, prolonging its life...


2021-03-06 16:25:34
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
I found a project that makes the set up pretty straightforward on platforms with systemd and npm. It's located at: patrikx3 /ramdisk. I've got it set up and it seems to be working well in my 32Gb system with a ramdisk size of 8Gb.


2021-03-06 18:32:19
Profile

Joined: 2012-08-08 17:51:35
Posts: 84
Reply with quote
I have no statistics to share, but I thought to chime in anyway.

The visual experience for me is a noticeably faster rendering of items inworld with the new cache in place. Houses, boats, structures, ... that kind of things.
(And that is with a regular spinning hard drive, no such speedy hardware as SSD's here yet :P)

Thanks Henri ^^


2021-03-07 14:46:57
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Jessica Hultcrantz wrote:
The visual experience for me is a noticeably faster rendering of items inworld with the new cache in place. Houses, boats, structures, ... that kind of things.
Since meshes do use that cache, it could indeed be an effect of this new, simpler (and thus faster) code.


2021-03-07 14:48:17
Profile WWW

Joined: 2011-10-07 10:39:20
Posts: 181
Reply with quote
It feels faster at least.

I wonder if that could would benefit from some io_uring or Windows IOCP goodies, especially on NVMe SSDs.
It looks much cleaner with the useless cruft removed.


2021-03-09 00:20:40
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
kathrine wrote:
It looks much cleaner with the useless cruft removed.
Not as clean as it should: next release will have a cleaner/safer/better/faster version...


2021-03-09 12:20:06
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

Who is online

Users browsing this forum: No registered users and 4 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.