HywelPhillips
September 6th, 2025, 15:44
Hi Everybody,
This is going to seem like a criticism of FGU, and it's really not. I just can't get my head around what the performance bottlenecks are for the software (and for VTT's in general for that matter, but I use FGU most and so notice its bottlenecks more).
Can someone explain to me, a veteran scientific FORTRAN programmer who has dabbled in new-fangled johnny-come-lately languages like Java, JavaScript, C++ and PHP what is it that's taking all the CPU cycles? Is it because we're running an interpreted language (LUA) on top of a game engine, and a lot of stuff gets limited to single-threading?
The GPU load I can understand. I'm running 2 x 5K retina screens, and figuring out what to do with order of 30 million pixels in 24 bit colour 50 times per second is not a trivial thing.
But we've got threads complaining that the new long reference manuals can break for stuff like monster books with 50-100 embedded pictures which just makes no sense to me. I wrote my PhD thesis on an Acorn Archimedes, a 32-bit 25 MHz RISC CPU and 8 MB of memory and an 80 MB hard drive and that could contain my 200 page thesis with hundreds of embedded diagrams in a word processor and run smooth as silk.
The FGU data structures are plain text XML rather than being handled by some super-streamlined machine code and compressed data formats. But surely a jump to running on the direct successor to that RISC CPU, a Mac Studio M2 Ultra at 4 GHz with 128 GB of memory and 8 TB of SSD REALLY ought to be able to handle a document with a few hundred pages and lots of pictures, even if the document size has blossomed because we're using plain text encoding and the graphic files are maybe 10 or even 100 times the size? The processing power is up by order of 1,000 just on CPU speed (in MIPS terms its more like 100,000), memory by order of 10,000 and my SSD is orders of magnitude faster than the original cache memory on that first-gen ARM CPU.
It's not a criticism, as I say. I just genuinely don't understand what the time sinks are. They are obviously THERE, as all the VTTs have these lags and delays, but I just don't get where the bottlenecks are and it's been gently bugging my autistic *** for a while now! I'm sure all the devs on all of the programs are far better at this that I ever was, and if there were ways to speed code up by orders of magnitude they would have been implemented years ago.
Can anyone explain it to me in language an idiot (or an ex-programmer whose ideas are 30 years out of date) will understand?
Like what fraction of the time does the program spend on various tasks? I know single-threading is a limit, and I can see that trying to index stuff like the assets window on the fly when I might have 50,000 items taking up 120 GB of space in my /images folder is fair enough (and it's got WAY quicker with caching and recent performance improvements).
But I just don't understand why stuff like text and graphics handling isn't essentially instant. Even a 4096 x 4096 x 24 bit graphic is only 50 MB uncompressed, isn't it? We're dealing with a system here with 800 GB/s of memory bandwidth and SSD 6+ GB/s read and write. Sure, you have to uncompress it from some heavily-mangled format like JPEG or WebP first but once you've got it in memory, shouldn't it be chucking these about like they are nothing? 20 of these files take up less than 1% of my system memory.
I understand that using it as map and doing all the ray tracing for line of sight for every token is an onerous task, but I don't get why these programs have any sort of lag dealing with static text and graphics. I'm running on what would have been considered an impossible super-computer in my particle physics days- I've got more computing power on my desk than the whole CERN central computing facility used to have back in the day - and I just don't understand why stuff that a 90's era word processor handled with aplomb is capable of challenging performance AT ALL. Likewise all the list building and database stuff for NPCs, abilities, etc.
But I've never written or worked on a distributed, time-synched GUI driven program like FGU and I have no idea what's going away behind the screen to eat up all the CPU cycles. Can some kind dev give me a few crumbs to satisfy my curiosity?
Cheers, Hywel
This is going to seem like a criticism of FGU, and it's really not. I just can't get my head around what the performance bottlenecks are for the software (and for VTT's in general for that matter, but I use FGU most and so notice its bottlenecks more).
Can someone explain to me, a veteran scientific FORTRAN programmer who has dabbled in new-fangled johnny-come-lately languages like Java, JavaScript, C++ and PHP what is it that's taking all the CPU cycles? Is it because we're running an interpreted language (LUA) on top of a game engine, and a lot of stuff gets limited to single-threading?
The GPU load I can understand. I'm running 2 x 5K retina screens, and figuring out what to do with order of 30 million pixels in 24 bit colour 50 times per second is not a trivial thing.
But we've got threads complaining that the new long reference manuals can break for stuff like monster books with 50-100 embedded pictures which just makes no sense to me. I wrote my PhD thesis on an Acorn Archimedes, a 32-bit 25 MHz RISC CPU and 8 MB of memory and an 80 MB hard drive and that could contain my 200 page thesis with hundreds of embedded diagrams in a word processor and run smooth as silk.
The FGU data structures are plain text XML rather than being handled by some super-streamlined machine code and compressed data formats. But surely a jump to running on the direct successor to that RISC CPU, a Mac Studio M2 Ultra at 4 GHz with 128 GB of memory and 8 TB of SSD REALLY ought to be able to handle a document with a few hundred pages and lots of pictures, even if the document size has blossomed because we're using plain text encoding and the graphic files are maybe 10 or even 100 times the size? The processing power is up by order of 1,000 just on CPU speed (in MIPS terms its more like 100,000), memory by order of 10,000 and my SSD is orders of magnitude faster than the original cache memory on that first-gen ARM CPU.
It's not a criticism, as I say. I just genuinely don't understand what the time sinks are. They are obviously THERE, as all the VTTs have these lags and delays, but I just don't get where the bottlenecks are and it's been gently bugging my autistic *** for a while now! I'm sure all the devs on all of the programs are far better at this that I ever was, and if there were ways to speed code up by orders of magnitude they would have been implemented years ago.
Can anyone explain it to me in language an idiot (or an ex-programmer whose ideas are 30 years out of date) will understand?
Like what fraction of the time does the program spend on various tasks? I know single-threading is a limit, and I can see that trying to index stuff like the assets window on the fly when I might have 50,000 items taking up 120 GB of space in my /images folder is fair enough (and it's got WAY quicker with caching and recent performance improvements).
But I just don't understand why stuff like text and graphics handling isn't essentially instant. Even a 4096 x 4096 x 24 bit graphic is only 50 MB uncompressed, isn't it? We're dealing with a system here with 800 GB/s of memory bandwidth and SSD 6+ GB/s read and write. Sure, you have to uncompress it from some heavily-mangled format like JPEG or WebP first but once you've got it in memory, shouldn't it be chucking these about like they are nothing? 20 of these files take up less than 1% of my system memory.
I understand that using it as map and doing all the ray tracing for line of sight for every token is an onerous task, but I don't get why these programs have any sort of lag dealing with static text and graphics. I'm running on what would have been considered an impossible super-computer in my particle physics days- I've got more computing power on my desk than the whole CERN central computing facility used to have back in the day - and I just don't understand why stuff that a 90's era word processor handled with aplomb is capable of challenging performance AT ALL. Likewise all the list building and database stuff for NPCs, abilities, etc.
But I've never written or worked on a distributed, time-synched GUI driven program like FGU and I have no idea what's going away behind the screen to eat up all the CPU cycles. Can some kind dev give me a few crumbs to satisfy my curiosity?
Cheers, Hywel