Hi
I had resisted optimise for a few reasons not least of which was the
wrap up problem fixed in D3 9 service pack 1.
I have now taken the plunge and things are going well.
The discussion on speed of matrix/dynamic array handling caused me to
review a lot of things. Kevins prompt to use System(12) for time
caused me to rerun them - I have avoided system calls over the years
because of platform incompatibilities.
The results are staggering;
SWAP 10,864 LF for AM dropped from 78 milliseconds to 16 milliseconds
Extract and display attributes from result dropped from 36.219 seconds
to 28.359 seconds
Dim(var) and display dropped from 1.578 seconds to 1.297 seconds
REMOVE and display dropped from 38.922 seconds to 1.156 seconds
DIM(20000) and display dropped from 1.641 to 1.047 seconds
Spectacular result REMOVE is optimised to the nth degree and now
proves Kevins point re dynamic if one uses REMOVE with optimise and
not Extract.
One is probably best advised to use unoptimised code for initial
testing of strange results as there are traps. Variable not assigned
a value does not show up until it crashes. Quite a nuisance if it was
passed to an external subroutine and that is where it crashed.
These speeds on an ancient XP machine by the way.
Peter McMurray

On 2011-07-20 20:21:21 -0400, Excalibur21 <pgmcmurray (AT) gmail (DOT) com> said:

We're still on the 7.x series around here. Is "Optimize" something new
for 9.x, or are you talking about Flash compilation?

WRT Flash compiling, we only do it for some programs because, while the
speed improvements can be fantastic, we've run across bugs that cause
unexpected behaviour when running Flash compiled code.

This probably isn't much of an issue for new code, as you can verify
behaviour as you develop, However, there's just no way that I'm going
to Flash all the programs in an account, which may be hundreds, and
hope that they just work.

--
Kevin Powick

Kevin Powick wrote:


I suspect he does mean the "O" option on Compile which originally
meant Optimise, and we had options o0 through o9. The numbers went
away after some years.

WRT Flash, I flash everything but in a controlled manner - exactly as
you say, with new code where I am testing constantly. I do trust
Flash and am not concerned about any anomalous behaviour. No, that
doesn't mean I would flash someone else's account and walk away. I
haven't seen a Flash-related issue in years, including the wrapup
issue Peter mentions, but I don't doubt there was an error of some
kind. Trust, but verify.

YMMV

On 2011-07-21 11:59:34 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:


I reported one to this group for D3/NT 7.5.6 about a year ago.

In the same thread, I also commented about the great number of
Flash-related bugs that were addressed in each service pack. So, I
think Flash bugs were (are?) more common than perhaps some believe. At
least it looked like there was an effort to get them squashed.

--
Kevin Powick

On Jul 21, 1:17*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
2010) is primarily due to the system crashes we were having, blamed by
RD tech support on "corrupt shared Flashed memory". The symptoms
were always the same, where first one user, then another, then many,
would encounter a drop to the system debugger. We would then have to
shut down D3 and reboot the server. The error produced was always
"PX_ILOAD" related. I was told that programs flashed without full-
path would be a strong consideration for the "PX_ILOAD" error. At
that time, we were on rev 7.4.1. In an attempt to resolve the issue,
RD teamed with our var and delivered a "test" server, built to the
exact configuration as our live 7.4.1 system (I wanted to remove all
doubt that hardware was at fault). That "test" system was loaded
with 7.5.x, and had the full complement of 130-users loaded.
Overnight, we off-loaded our database to the new server. We started
the system at 7AM, and by 9AM, we were logging so many "PX_ILOAD"
errors that we had to take it down and revert to the 7.4.1 server.
The repetition of these "crashes", without a final fix to the problem
was the ultimate decision-maker for me to leave D3.

I never heard whether or not the error was found/fixed. And, I never
heard anything else as a possible cause, except for flash-related
issues.

Jim Cronin
Kittery Trading Post

On Jul 22, 5:14*am, JJCSR <JCro... (AT) ktp (DOT) com> wrote:
Hi
I an certain that D3 9 is a very different beast to earlier versions.
There have been significant TigerLogic management improvements to get
to this point.
All my programs are subroutines to a master controller so Flash
optimising one was not possible, it was all or nothing.
Nothing won! However some things only work in optimised code so I bit
the bullet for new work.
I also put up a second account to get around the issue on an existing
site. The new account only had access to a small subset of optimised
programs but all the files. .
Not nice as I hate two copies of anything but it solved the client's
problem. Service pack 1 on D3 9 has it all optimised
If one is going to use the new interfaces for the Web and .Net the
speed and function availability do become an issue.
I had wondered what tipped Kittery after all this time. A hard
decision for very valid reasons.
Now if we could just get TigerLogic to start a tip of the week like QM
or a news letter a la NorthgateArinso or RocketU2 or Cache. Could
somebody please explain the Arinso unfortunately Rinso is a washing
powder :-)
Peter McMurray

The best way to solve D3/NT issues is to migrate to D3/Linux. Quick,
painless & rock solid :-)

Kevin Powick wrote:

I Did end that sentence with ", including the wrapup issue Peter
mentions, but I don't doubt there was an error of some kind." I
thought that the context conveyed the intent, which was that I have
not personnally seen Flash-related issues on my development systems
nor in my clients' systems. I was just conveying personal experience.
That didn't include comments read here nor to imply that because "I"
didn't experience problems that such didn't exist.

That said, I've been thinking about this a while, and I'm wrong. I do
recall a few errors now, a couple of which were reported and a couple
that I ignored or forgot until now. Just keeping it real...

T

Excalibur21 wrote:
I hate to tell you after the fact but you probably only needed one
code set. Just create two catalogued verb entry points into your
code, one for flashed code and one for unflashed. Once a code module
is entered, it will continue to use the flashed or unflashed modules
of all subs that it calls. So for example:

You have one program called MENU which branches everywhere else. You
have a standard catalog entry in your MD called MENU. When this calls
your MENU program, if a flash module is available it uses that. When
MENU calls CUST.MAINT, it executes that program's flashed module and
so on. Now, copy the MENU verb to MENU.NON.FLASHED, MENU2 or similar.
Change ATB1 to VR1. Now when you execute that verb it calls the
standard/unflashed object for MENU, which in turn calls the unflashed
module for CUST.MAINT and everything else.

That's it. You need one extra item in the MD, not a copy of your
entire programs file in another account. If you need code to behave
differently, you can write some code to check. I apologise but I
don't recall off-hand how to properly check that. (I don't think it's
system(36)). In short your code would do something like this:
GOSUB CHECKED.FLASHED ; * Include this mystery code
IF IS.FLASHED THEN ...
END ELSE ...

Why would you need to do that? Well, there are still differences
between Flashed and Non-Flashed code. The documentation (where Peter
found the notes on "001"#"1") isn't very good, but but at least it
gives you a heads-up where things might require scrutiny.


What's wrong with the tech tips from the 1990's?
You want MORE? So greeeeeeeedy...

Seriously, my suggestion to them also went nowhere:
http://forums.tigerlogic.com/index.php?showtopic=1761

As a placebo, see the few notes on my blog:
nospamNebula-RnD.com/blog/category/tech/mv/d3

Back in the 80's and '90s there was the "SSelect" newsletter (IIRC)
which was usually quite informative, but for-fee. Isn't it
interesting and a shame that the demand for Free information has
virtually killed the supply of Any indepth information? If people
placed a value on information, uh which is of value to them, we might
have a much higher signal to noise ratio in this community. Case in
point, as a social experiment I offered to sell information to speed
large document generation by a factor of 20:1 and no one was
interested. Hey, that's our market.

That said, we do have PickWiki which is a free repository where anyone
can post and read information. If you don't get what you need from
your vendors, try to find something that will motivate your colleagues
to post there. I know it's not the same. We'd hope that the vendors
can provide insight not available in their documentation or elsewhere.
So far that hasn't really been the case but at least some of the
vendors are trying. Whatevah ... viva le techtips!

T

On 2011-07-22 02:08:01 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

Understood. It was just that considering how much and how deeply you
are known to delve into the intricacies of many systems, it seemed odd
that you've experienced so few bugs. If anyone, I though you would
have a great list of discovered corner cases.

--
Kevin Powick