Java software deployment problem? ?

[Peter]

Hi all
I am developing a software by Java, Within it, there is a complex
JTable with complex cell renderer. It run smoothly on P4 2.2GHz,
normal on 1.8GHz, quite slow on P3 733Mhz.

The JTable is highly optimized, i can do nothing on the code now.
If i write P4 2.2GHz requirment on my software box. It is too crazy.
Why should i do?

What is your feeling when you see this requirement and will it
stop you to buy my software?

thanks
from Peter ([email protected])

 

[Chris Uppal]

The JTable is highly optimized, i can do nothing on the code now.
If i write P4 2.2GHz requirment on my software box. It is too crazy.
Why should i do?

Is this complexity in fact necessary ? Is it something that you could make
optional so that users with less powerful machines would turn it off (or users
with powerful machines could turn it on) ?

What is your feeling when you see this requirement and will it
stop you to buy my software?

Personally, I never read the hardware requirements -- I don't believe them, so
why bother reading them ?

But if I tried your software and it ran that slowly (i.e. only running well on
my fastest machine) then I'd be quite critical unless it were clear that the
complexity causing the slowness was actually providing considerable added value
to *me*.

-- chris

 

[nos]

could it be a memory problem?
faster machines usually have more memory too

 

[Peter]

Mustn't be a memory size problem.

Run slow on 1.8GHz, 384 SD Ram.
Run Fast on 2.2Ghz, 192 DDR Ram.

May be DDR problem , i don't know. check it out later.

thanks for reply

 

[Peter]

thanks for reply first
I think successful software must look good. You try Apple itune,
it run a little bit slow , but it has beautiful UI, so many people
still use it.

My JTable in my software is slow in vertical scrolling and
highlighting the corresponding row. I don't want to simple down the
data outlook of it. Beautiful UI is very important for my company.

If you buy a software that run slow on your computer, will it stop
you to buy software again from that company in the future?

thanks
from Peter ([email protected])

 

[Christophe Vanfleteren]

Mustn't be a memory size problem.

Run slow on 1.8GHz, 384 SD Ram.
Run Fast on 2.2Ghz, 192 DDR Ram.

May be DDR problem , i don't know. check it out later.

thanks for reply

Maybe there is something wrong with the graphics drivers on the slower
computer which slows down the rendering. It shouldn't be that much slower in
normal conditions. Have you checked cpu and memory usage of your program
while it's running?

 

[Fred]

First: most boxes don't simply have "required", most have "required"
AND "recommended".

Personally, I don't buy anything unless I have the "recommended"
hardware minumum, because "required" is really a code to tell people
that it will run, but it won't be pretty.

To your last question: buying something that ran really slow would NOT
prevent me from buying software from that company in the future,
because each project is usually so different, and given a large enough
company has different groups of people working on them... it would
have very little influence on me.

As far as beauty/speed is concerned, as someone else pointed out, it's
better to have a happy medium. Frankly, my father (the accountant),
after Windows became the norm, would yearn for the days of DOS Lotus
123... the computers just weren't fast enough with the fancy GUIs for
a long time. Now it's not so much of an issue. I mention someone
like my father because he's your typical computer user - you won't be
hearing responses from people like that here. Being pragmatic, he'd
rather have the speed then the eye candy. Me too.

 

[jenniferyiu]

you are asking my feeling.

well, 1st of all my feeling about what you wrote is --


HA HA HA !!!

 

[Scott Ellsworth]

I am developing a software by Java, Within it, there is a complex
JTable with complex cell renderer. It run smoothly on P4 2.2GHz,
normal on 1.8GHz, quite slow on P3 733Mhz.

Fix up the renderer, unless you know that your users will have high end
machines. Remember also that laptops are slower than desktops, so if
you want laptop users, you will have to revise your machine speed
estimates downward.

The JTable is highly optimized, i can do nothing on the code now.
If i write P4 2.2GHz requirment on my software box. It is too crazy.
Why should i do?

Were it my app, I would profile the hell out of it, and see if I could
precompute the table entries. For example, show just pages rather than
the whole table, or perhaps turn complex on-the-fly graphics into static
images.

Perhaps an LRU cache if you have big as well as slow objects.

You also might want to try it on a Linux and a Mac machine, to see if it
behaves the same there, and on 1.3 and 1.4 VMs, as your users might fit
any of those categories, and "smoothly" might become "wretched" under a
different platform or VM.

There is absolutely nothing you can do if you cannot change the code.

What is your feeling when you see this requirement and will it
stop you to buy my software?

It would stop me cold, for two reasons.

First off, I use a Mac, and so I would not be happy with an app that was
PC only, especially if it is an app that could in theory run anywhere.

Assuming that it is PC-only, I have easy access to a 450MHz model. I
can probably borrow a 1Ghz if I had to test an app, but I would not be
eager. Again, remember that laptop users often have much slower
machines - a technophile tablet user I know replaced his 1GHz laptop
with a 867 MHz tablet, and that is all he uses now. Further,many
companies have dropped to a three, four, or even five year replacement
schedule for internal machines.

Scott
(e-mail address removed)
Java, Cocoa, WebObjects, and Database consulting

 

[Scott Ellsworth]

I think successful software must look good. You try Apple itune,
it run a little bit slow , but it has beautiful UI, so many people
still use it.

It must look good, but it must also work. If it fails to work well,
then all of the look in the world will not help. If, on the other hand,
it does the job, then the user will pick the one they like to use.

Also, a lousy look or bad feel can make an app not work. Even if the
software can handle the job, if I cannot figure out how to make it do so
in the time I have, then it did not do the job, and that is all in UI
design.

I find iTunes acceptably fast on my 667 MHz machine, so I do not
complain. I found iPhoto unacceptably slow on the same hardware, filed
bugs, and now use it as little as possible until they patch it. Had I
used iPhoto first, I probably would not have been at all eager to try
iTunes, but I used them in the reverse order.

My JTable in my software is slow in vertical scrolling and
highlighting the corresponding row. I don't want to simple down the
data outlook of it. Beautiful UI is very important for my company.

You might want to add properties to dumb down the look. This way, a
user with a lower class machine can run it and get acceptable
performance. Users do NOT like waiting while things scroll.

If you buy a software that run slow on your computer, will it stop
you to buy software again from that company in the future?

I will always remember the stellar and the crummy performers. Some
companies have delivered both, and I am careful about those. I try to
buy from the good ones, and to avoid the bad ones.

Think of it this way - if you ship an app that is too slow to use, some
users will never, ever try an app by you or your company again. Others
will. Those users who see a good app by you or your company first will
wonder what went wrong with this one if it is too slow for them to use.

Scott
(e-mail address removed)
Java, Cocoa, WebObjects, and Database consulting

 

[Peter]

It must look good, but it must also work. If it fails to work well,
then all of the look in the world will not help. If, on the other hand,
it does the job, then the user will pick the one they like to use.

Also, a lousy look or bad feel can make an app not work. Even if the
software can handle the job, if I cannot figure out how to make it do so
in the time I have, then it did not do the job, and that is all in UI
design.

I find iTunes acceptably fast on my 667 MHz machine, so I do not
complain. I found iPhoto unacceptably slow on the same hardware, filed
bugs, and now use it as little as possible until they patch it. Had I
used iPhoto first, I probably would not have been at all eager to try
iTunes, but I used them in the reverse order.


You might want to add properties to dumb down the look. This way, a
user with a lower class machine can run it and get acceptable
performance. Users do NOT like waiting while things scroll.


I will always remember the stellar and the crummy performers. Some
companies have delivered both, and I am careful about those. I try to
buy from the good ones, and to avoid the bad ones.

Think of it this way - if you ship an app that is too slow to use, some
users will never, ever try an app by you or your company again. Others
will. Those users who see a good app by you or your company first will
wonder what went wrong with this one if it is too slow for them to use.

Scott
(e-mail address removed)
Java, Cocoa, WebObjects, and Database consulting

thanks for you advise
But how can i do this "You might want to add properties to dumb down the look"?

thanks again
from Peter ([email protected])

 

[Scott Ellsworth]

thanks for you advise
But how can i do this "You might want to add properties to dumb down the
look"?

In one of my apps, I display a table of information. Among the
information is a summary statistic for every entity in the model and its
distance to the other items. This is an n^2 problem that also involves
some multiplies and a square root, so it is not cheap once there are
more that a few hundred items. On a fast machine, it can handle up to
500 or so, and the typical use case is between 100 and 500.

If the system property "com.iceweasel.avoidSlowSummaryStats" is set to
true, then it does not calculate those stats, and thus does not do a
traversal of the model.

e.g.

if (System.getPropertyValue("com.iceweasel.avoidSlowSummaryStats",
"FALSE").equalsIgnoreCase("True")){
doSlowTraversalStat();
}

Obviously, one should query the property once on startup, not every time
through the display loop or in getValue, but this is the basic idea.

If it turns out to be a major time sink, and I feel that the program is
not useful without it, then I will try to come up with a better
algorithm, such as a clustering n log n or a "compute on add" option.
This will slow down adds substantially, but that might be acceptable,
especially if I can pre-compute it for static data. This is complicated
enough, though, that I do not want to do it unless I have to.

So, by providing the property, I allow users on even marginal hardware
to use the tool even before I optimize it. They do have to know the
magic property, but if need be, I can do some groking of the hardware
itself and disable things by default. I far prefer to leave the user in
control, and giving them a magic property or preference pane is a lot
better that trying to guess what they want, and whether they prefer slow
scrolling or missing information.

Once one does provide such properties, it is not hard to move setting
them into a preference pane if they seem to be commonly used. Pref
panes are, of course, better than magic properties, but magic properties
are easy to implement in early stages, and as you move towards release,
you can migrate critical parameters to something with a UI.

I also try to provide some of the marginal parameters, like the number
of records to return from the database at a time, or whether one should
preflight the db queries for the size of the result set, as magic
properties.

In summary, by having the most expensive features of my app appear by
default, but not appear if special magic properties are set, I can
distribute a launcher file that runs the stripped down version for slow
machines.

Scott
(e-mail address removed)
Java, Cocoa, WebObjects, and Database consulting