It takes a while to launch such a simple/small program.
This seems to be related to the "Prefs/Presets/tbimages" icons scan/load, which is even bigger now (8931 files now, vs 5461 on OS4.1.6).
Is there a way to speed it up? Not just FS change (I use the system default, DOS\07), which maybe a temporary solution, untill more filles are added. An alphabetical directory split, or icon categories directory, might be a solution for a future OS update?
@Cass It is known problem. When AISS installed to partition which is FFS, then loading of any app which use AISS take a lot. For example, on my old pegasos2, to run diskimage it take 10-20 seconds or something. Same for notepad or anything else.
And problem is that whole AISS structured bad : a lot of small little files. While its ok for sfs, ngfs, etc, for ffs it is killer.
The only solution copy all AISS stuff to other partition (not ffs one), and reassing those tbiamges to that place. Of course it is AISS which should be structured somehow different (i.e. not just one directory with thousands of files), but that up to Martin. From user's side only partition change help.
FFS is known to especially have very bad performance when the number of files in a directory becomes big. The only proper solution is to store AISS on another filesystem, either by changing your system partition to something else or by moving AISS, like kas1e suggests.
If you really hate the thought of doing that, you might be able to hack an alternative solution by moving the images into lots of subdirs, like you suggest, and then do an Assign ADD for each of them to TBImages: in User-Startup. I do something similar with my CDDB: assign *). But it will be a bit messy, and you'll have to do it again every time AISS is updated.
Best regards,
Niels
*)
For inspiration, here's how I do that in my User-Startup:
Someday hyperion should made ffs as depricated, and just provide read-only one support for one or two updates before get rid of it totally in favor of ngfs. Sure, some old progamms from 68k era will not works, but that ffs thing with all this slow work, validatino, non journaling and so on should give us a rest one day.
@kas1e No, FFS support should *always* be kept, at the very least to allow data transfer to/from other Amiga-like OSes.
Also, FFS is extremely well-tested & robust (albiet slow), so there are surely valid use-cases for using it instead of NGFS/SFS/etc.
Also, FFS is *needed* for the X1000 to boot, since that's the only Amiga filing system that it's "BIOS" (CFE) can read "amigaboot.of". And that might need updating/recreating at some point.
Now MAYBE support for booting from FFS should be depreciated... but even that seems a bit heavy-handed.
IMHO just don't supply pre-built Amiga systems with FFS as the boot partition. Maybe MediaToolbox should give an annoying warning any time FFS is chosen?
@Andy There is already lots of things which was depracated without legacy support in last 10 years , so even if ADF nto IDF0: will not work, let it be. Use UAE for or something :)
@ChrisH Probably will be good to reject "Boot" flag for FFS at all. Not just in mediatoolbox, but just made a change in FFS so boot flag will be ignored always, whole FFS will be read-only, and in mediatoolbox will be fat remark "FFS CAN'T BE USED FOR BOOTING".
Even if it well tested and robust its so old and bad in perfamance that someday should die.
But if it was me, i just remove it at once. Users will moan a bit for a while, and then all will be ok :) They will found ways how to deal and with what, maybe those hardcore ones who want FFS will grab it from old updates and install it manually (like SFS now), and everyone will happy, just from OS side all will be clean, and everyone will be on ngfs.
Maybe Olaf (or hyperion itself, who is own it) , can just make it as 3d party handler and upload to os4depot. But it has no way to be in OS, imho.
I remember how long it take for me when i realize that its all slow runnng because of FFS + AISS combo, and of course, i wasn't happy to remake system partiion, and put AISS on sfs work partiion => not clean mess. Instead, if i was told at beginin of installation "NO FFS FOR BOOT PLEASE, IT WILL SLOW YOUR PERFOMATCE A LOT" , at least that can help a little.
@kas1e I strongly disagree with removing FFS. The deprecated items you refer to are not supported for new OS4 applications but remain accesible by 68k applications. Not supported doesn't mean they are gone. Some are still needed to run 68k applications under OS4 emulation. In fact, deprecated AmigaDOS functions are used/needed by Dopus5. For one thing, the 64bit filesize system that BSzili designed to work on all platforms relies on the fact that the deprecated AmigaDOS functions in OS4 still work.
The CFE partition on an X1000 is the first partition that must be FFS. There are too many complications that could arise from removing FFS. SFS is no longer under the control of OS4 devs; it's now a 3rd party add-on. Even if the new filesystem is released for all OS4 hardware, we need a reliable OS4 owned alternative filesystem. Leave FFS right where it is.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@Xenic Yeah, i remember all that about dopus5, but its anyway wrong how we do it all in generall, we just go easy route, as rewriting big parts of dopus5 are hard and very time consuming. Deprecated functions deprecated not just for fun, but to have ability to grow in features later :)
As for SFS, sure it is gone, but there is NGFS now, which is good alredy.
But all that imho of course as pure user from perspective not of amiga user, but from some new user who install os on ffs and will think "damn, what piece of slow shit is it! apps loading 10-20 seconds!" , and go explain him that FFS there "because why to remove it, its ok, just not use it for boot, or use, just not use aiss on it, or use, just make subdirs for it" :)
@xenic I mean FFS can be depracated from OS , but being able to download manually for those ones who need it. By this way, no one who do not need ffs (probably all newcomers) will by ancident setup ffs as boot partiion.
But that all not so matter to discuss, as we not hyperion :)