I shipped my first BDS2006-built system
Scout
It is an update of something I wrote in D7, but the users who got the
BDS2006 system have never seen the D7 system.
It uses update #2, is stable and fast, and offers much over what they
were using before.
The only negative feedback I have received to date is that some
searches are slower than in the old system.
This is a very large system where searching is not the main focus, and
searching in the new system is _almost_ always orders of magnitudes
faster than in the old system. But there's always an edge case.
I wrote both the old system and the new system. The old system is
single-user, the new system is multi-user.
The best case search in the old system is always going to be faster
than the best case search in the new system since the multi-user nature
of the new system implies a little bit more house-keeping.
A worst case search in the old system could tie up the computer for
many minutes at a time. The same worst case search might take half a
second in the new system.
Isn't it amazing that people can ignore everything that has been
improved and concentrate instead on the one thing that might take a
little bit longer?
I reckon there are bunch of similar attitudes about the new IDE. If
the IDE crashes or goes into La La land for a couple of minutes, then
there is cause for complaint, but mostly the new IDE is better, more
functional, and sufficiently fast for anything that I need.
Thanks Borland, and raspberries to anyone who complains about my new
system's search speed.
Scout
Dennis Landi
>
> Isn't it amazing that people can ignore everything that has been
> improved and concentrate instead on the one thing that might take a
> little bit longer?
>
But not surprising. Perceived Performance ("How long am I waiting?") is
the number one bugaboo for customers using debugged systems. IOW, the
app may work perfectly; but if its users thinks its "slow" the users
will never be totally happy.
They'll say: "It works, but...." The problem is once the design has
been implemented, architectural (Design) improvements will be difficult
to make and you are left with small tactical options:
- Can the tables be better indexed?
- Can the SQL Queries be optimized?
- Can I refactor my code for more efficiency.
- Can the insertion of FastCode routines in strategic places make a
difference?
etc.
Tactics not Strategy are left as options. In your case some of the
tactics mentioned above may be all you need.
-d
Peter Morris [Droopy eyes software]
I have a large company potentially interesting in buying the rights to some
software my company owns. I recently recompiled it in BDS2006 before
letting them have an evaluation.
Brion L. Webster
> Thanks Borland, and raspberries to anyone who complains about my new
>system's search speed.
Can I have mine over a slice of cheesecake? ;-)
--
-Brion
There's no such thing as 'one, true way;'
- Mercedes Lackey
Brett Watters
> Isn't it amazing that people can ignore everything that has been
> improved and concentrate instead on the one thing that might take a
> little bit longer?
Perhaps. However, if you job involved searching hundreds of time
each day, then you it isn't "one thing", there is no "might", and "a bit"
often equals hundreds of hours of waiting.
That is like saying that in D2005 that a three second pause while
you are typing is a small price to pay for all the code insight,
refactoring, etc. Well, I can't type in D2005. I spend 90% of
my time typing and maybe 0.01% of my time looking at the
code insight, refactoring, etc. I'd trade 5 minutes every few
hours looking something up in the help file rather than "a bit"
of waiting two hundred times and hour.
People rarely use programs the way the developers do. They
use one feature over, and over, and over, and over. The other
90% of the product gets used maybe 1% of the time.
Scout
system. And even if it was, 95% of the time the search performs much
faster on the new system than on the old system.
Scout
says...
you make good points, but the strategy the new system uses has to live
with the overhead of being multi-user whereas the old system could
ignore that.
The search capability is already incredibly fast, but in some cases
not quite as fast as the old system. 95% of the time, the new system is
faster than the old. For the remaining 5% of the cases we're comparing
300mS with 600mS. The old system would also crash frequently whilst
there has yet to be a single instance of a crash recorded with the new
system.
In the edge cases where the old system is faster than the new, I can
see why it is faster. I had optimizied the heck out of that specific
case with BASM and the knowledge that I had exclusive control over what
the CPU was up to. The new system doesn't have that luxury.
Scout