marbru@auto-trol.UUCP (Martin Brunecky) (09/25/90)
Xrm is really a good piece of code. The way it optimizes resource access
for Xt looks really good. However, nothing is as good that it can't be
improved.
As I looked through Xrm.c, I suddenly realized that we should look for some
improvements here and there. The fast resource lookup in Xrm is not free
(well, nothing ever is). Consider the following, very simple example:
menu.background: blue
menu.btn1.label: A
menu.btn2.label: B
....
According to my poor estimates, the data structures created to navigate to
the 3 resource values above add to 924 bytes, not counting value strings
itself and not counting the space needed to compute quarks:
26+256+26 bytes for the line 1 (menu bucket, tight hash table, bucket)
26+256+26 bytes for the line 2 (btn1 bucket, tight hash table, bucket)
26+256+26 bytes for the line 3 (btn2 bucket, tight hash table, bucket)
For each additional button, add 308 bytes. This is, of course, almost the
worst case scenario. For each additional name (resource) added to "btn1"
I will pay "only" 26 bytes (bucket) overhead. It may, however, get even
worse if I mix in some loose bindings.
Since I am using Xrm LOTS, I was horrified. May machine has a VIRTUAL
memory (of course). But when populated with sparse data, give me a system
that pages well. Sure, I can play games and optimize my Xrm definition(s)
to storage requirements. But do I want to ? Do I have to ?
I believe there are ways to improve the Xrm storage efficiency, and thus
performance on real, limited physical memory systems. Without having to
sacrifize performance. The current sample implementation uses a single
bucket type, with a fixed size of hash tables. Why not have a different
bucket for branch and leaf nodes. There is always much more leaves than
branches. Why not have a variable hash table size. Each branch bucket
can start with a minimum hash table size. As names are added to this
bucket, the count can be monitored, and when it exceeds a reasonable
limit, we can rehash using a larger hash table.
For example, dropping the initial hash table size to 4 (from the default
of 64) would save 720 bytes in my example. Together with having a limited
"leaf" bucket of 12 bytes, a "branch" bucket without the "leaf" data (but
plus hash size and mask) of 20 bytes, my example would drop from 924 bytes
down to 144. And, may be, my buttons should start without a hash table
at all (down to 112 bytes).
And there is probably more that can be done.
So - yet another R5 wish list item. Or is there a good soul that has the
guts and the time to look and play with Xrm.c ?
--
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky marbru@auto-trol.COM
(303) 252-2499 {...}ncar!ico!auto-trol!marbru
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404 rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/26/90)
Xrm is really a good piece of code.
Actually, I think the use of Quarks was a major design bug.
Sure, I can play games and optimize my Xrm definition(s)
to storage requirements. But do I want to ? Do I have to ?
You don't want to. We don't want to either, but we probably will.
I believe there are ways to improve the Xrm storage efficiency, and thus
performance on real, limited physical memory systems. Without having to
sacrifize performance.
Yes, we've already been considering possibilities.marbru@auto-trol.UUCP (Martin Brunecky) (09/27/90)
In article <9009261335.AA09586@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > > Xrm is really a good piece of code. > >Actually, I think the use of Quarks was a major design bug. > I am sorry... I did not mean to talk about quarks, as the Xrm.c code can deal equally well with any identifiers, as long as they are uniform size. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404