ZTree.com  | ZEN  | About...  

 Index   Back

MB instead of KB view.   [General]

By: Ramon Ebdon       
Date: Oct 01,2003 at 10:45
In Response to: MB instead of KB view. (Walter Rassbach)

> I never said anything about performance, just about screen space.

> However, "options" are no where near free. There has to be code
> that is executed every time to see which way the option is set (in other
> words, for pretty much ever number displayed), and that code gets executed
> on everyone's machine, not just yours, and many of us don't run
> exclusively on fast machines (i have something like 6, from 266 all the
> way up) -- ZTree is for all of us and we have to recognize that other
> people run in other environments. To be honest, it would be a nightmare to
> program and maintain and will lead to endless buglets (well, Kim may make
> me eat those words, because my guess is that he has most of that stuff
> nicely isolated and encapsulated).

So, whats the performance "hit" for you on a 266mhz machine when you enable the Alt+K (Size) Treestats ?
I already made a post mention about the fact that theres an option to change the divider from 1024 to 1000 in the Options screen.
So how is there a real world noticable difference between using a feature thats *ALREADY THERE* and simply changing the divider to 1000000 or 1048576 instead of 1000 or 1024 ?

The screen I'm talking about:
Alt+F10 options, second page "Display Format" - Option E - "Kilobytes displayed as multiples of:" 1000 or 1024.
Obviously, no one but Kim can answer this, but I dont see how hard it would be to add a slight change to *enhance* this *already existing* feature.

> The other problem with "options" is that they lead quickly to
> bloat (which also costs time in terms of loading and memory resource
> usage, both of which ZTree is outstanding about). Kim has done an
> unimaginable job in being very careful about what options he has
> implemented, trading function against cost very well.

The Alt+K Treestats information itself is the option(since you dont have to use it), what I'm requesting is an enhancement/extension of that.
I agree wholeheartedly on the excellence shown thus far in keeping Ztree fast & while implementing new features.

> You can try to make a functional case why planting "mbytes"
> rather than the "noise" digits is better function and people
> will listen to those arguments with fairly open minds (well, Michael might
> be an exception ;-). However, a purely personal esthetic argument that the
> extra digits are a bother is gonna fail on deafer ears since there are
> clear usages (admitedly by only some of us) where having that information
> is useful -- In other words, you are going to have to come up with a
> stronger argument than: "I don't like it".

I've already stated that removing the extra (4) characters not required when using MB instead of KB would allow more characters in the Dir Name.
If you have not seen this problem occur where the Dir Name is truncated due to the Treestats being there, then you should try creating some really long ones.
When dealing with fixed width text and a fixed number of columns, every extra one counts. I dont understand why there would be such a resistance to *improve* the visibility of Directory Names.

Thread locked

Messages in this Thread

95,562 Postings in 12,054 Threads, 350 registered users, 47 users online (0 registered, 47 guests)
Index | Admin contact |   Forum Time: Sep 16, 2021 - 9:47 pm UTC  |  Hits:42,623,489  (18,300 Today )
RSS Feed