If you don't find the answer to your question here, please look at XFolder's web homepage also. XFolder's author is now maintaining a public bug list, which might answer your question too.
I don't think this is true in general. I have not done any tests, but in general, XFolder only slows down certain WPS features, but not the WPS in general.
The most obvious slowdown is opening context menus. Although the 50-objects limit which existed in XFolder versions prior to 0.70 has been lifted, you should still not put too many objects into the configuration folders. Since these folders are re-read every time a context menu is opened, XFolder might slow down the system too much.
With the other functions, I don't know. Naturally, painting the status bars does take some time, but this is normally not noticeable.
Also, XFolder doesn't use that much memory. I have checked this on my system, and in addition to the size of the XFolder DLLs, XFolder acquires only some 100 to 400 KB, depending on how long the WPS has been running.
XFolder now uses the WarpSans font for most of its dialogs, because it's so much prettier than "System Proportional". This font only comes with OS/2 Warp 4, so on Warp 3 it's not found, and the system uses the default system font (System Proportional) instead. If you can get hold of some Warp 4 \OS2\DLL\DSPRES.DLL file, simply copy it over the same file in your Warp 3 \OS2\DLL directory. This file contains many system resources, among others the WarpSans font. Warp 3 will work with the Warp 4 version without problems. (This only works if you boot OS/2 to the command line, using Alt-F1 at startup.)
You will need to install them first. See the corresponding page for more.
If you're using VisualAge C++ or any other software which installs SOM runtimes, make sure that SOM.DLL is loaded from \OS2\DLL. This DLL has been updated with more recent Warp fixpaks. VAC++ puts additional directories at the beginning of the LIBPATH statement in CONFIG.SYS, which still causes the old DLL to be loaded. Put those directories behind \OS2\DLL in the LIBPATH.
This is tricky. Some people have reported this in all variations, i.e. hotkeys work for the Desktop only, or not in URL folders, or not in Group Folders (an IBM EWS utility), etc.pp.. The same applies to status bars.
From what I can see, this is related to folder subclassing. XFolder needs certain window messages to introduce these features, and if some other WPS class intercepts these messages, XFolder's features behave funny or cause crashes or do simply not work.
In general, the more WPS class replacements you have installed, the more likely these errors are likely to appear. With a "clean" WPS, XFolder usually works fine, but the people who have reported these errors sometimes had four folder class replacements installed, and it's really difficult for me to track down these errors then. Try to de-install some WPS extensions which you don't absolutely need.
Also, the more messed up your INI files are, the more likely the WPS is going to become unstable in general. I strongly recommend Henk Kelder's WPTOOLS package, which you should run from time to time anyways, to clean up the INI files. This is still continually updated and available at Hobbes.
I have also found that installation order is important. Some WPS extensions seem to simply "swallow" messages which they don't need, assuming that they are the only WPS extension on the system. (This might apply to XFolder also, but I have tried to avoid this.) Now, if XFolder comes before this greedy WPS extension in the WPS class replacement list, which is the case if XFolder was installed first, it does get the message before the other WPS extension.
In theory, yes. Practically, sometimes. For details about this (and for other WPS utilities also), see the separate "Compatibility" page.
The reason for this is that the XFolder status bars query the free space on a drive. If the first object in your "Drives" folder represents a floppy drive, it's this drive that's queried.
To avoid this, change the status bar information for WPDisk objects in the "Workplace Shell" object, page 2 of "Status bars". Then this information will not be queried.
Alternatively, you can disable status bars for the "Drives" folder only on the "XFolder" page in the Drives folder's settings notebook.
No.