Slow & memmove()

Using the new 6.2 NC I just went into the Helpviewer for the first time and
watched while it built the help topic database on my admittedly slow 166
Pentium. Ok, so my mere 166 Pentium isn’t a screemer by today’s standards.
What I noticed was that the process slowed down as it progressed. I.E. At
first it was able to do several thousand topics a second, then about 1000 a
second then it took several seconds to do 1000 topics, then more seconds per
1000.

My application specialty is data bases. I have written many custom high
speed data bases over the years. This is the classic overhead of inserting
an index entry into an array that keeps getting bigger and bigger. But it
should not have slowed down so much in just 35,000 entries (I didn’t notice
the exact number). A smarter hashing algorithm is definitely needed.

I noticed this same problem when I ported my data bases to V 6. The biggest
problem I found was that while every single process bound function is slower
in V6 (as compared to V4) the memmove() function was a real pig. I re-wrote
memmove() and posted the asm code here (one of these newsgroups, I forget
which ) several months ago. I really, really, Really, REALLY suggest that
you incorporate my version of memmove into the general libraries. It will
speed up everything that pushes data around. My data base application went
from taking 3 hours to index a 4,000,000 record multi-key data base to about
26 minutes, with no other change.

P.S.

Found my post, qdn.public.qnxrtp.devtools “OUCH - A LOT ! !” dated Tuesday,
October 30, 2001 7:58 PM with an attachment. Don’t use the Oct 26 post! It
had a bug.

Add a decent search engine to the online help and then we might be able to
find the information we need…

Jim

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aeb0l9$oni$1@inn.qnx.com

Using the new 6.2 NC I just went into the Helpviewer for the first time
and
watched while it built the help topic database on my admittedly slow 166
Pentium. Ok, so my mere 166 Pentium isn’t a screemer by today’s
standards.
What I noticed was that the process slowed down as it progressed. I.E.
At
first it was able to do several thousand topics a second, then about 1000
a
second then it took several seconds to do 1000 topics, then more seconds
per
1000.

My application specialty is data bases. I have written many custom high
speed data bases over the years. This is the classic overhead of
inserting
an index entry into an array that keeps getting bigger and bigger. But it
should not have slowed down so much in just 35,000 entries (I didn’t
notice
the exact number). A smarter hashing algorithm is definitely needed.

I noticed this same problem when I ported my data bases to V 6. The
biggest
problem I found was that while every single process bound function is
slower
in V6 (as compared to V4) the memmove() function was a real pig. I
re-wrote
memmove() and posted the asm code here (one of these newsgroups, I forget
which ) several months ago. I really, really, Really, REALLY suggest that
you incorporate my version of memmove into the general libraries. It will
speed up everything that pushes data around. My data base application
went
from taking 3 hours to index a 4,000,000 record multi-key data base to
about
26 minutes, with no other change.

P.S.

Found my post, qdn.public.qnxrtp.devtools “OUCH - A LOT ! !” dated
Tuesday,
October 30, 2001 7:58 PM with an attachment. Don’t use the Oct 26 post!
It
had a bug.

Would http://www.htdig.org do the trick?

BTW, in regards to memmove() where does the STD C library come from in QNX
(GCC or Dinkum Ware?). Either way, that would be where to try and get the
replacement x86 version included. Otherwise, QNX is ELF format, so
LD_PRELOAD=mymemove.so should work, no?

“Jim Douglas” <jim@dramatec.co.uk> wrote in message
news:aeb772$t53$1@inn.qnx.com

Add a decent search engine to the online help and then we might be able to
find the information we need…

Jim

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:aeb0l9$oni$> 1@inn.qnx.com> …
Using the new 6.2 NC I just went into the Helpviewer for the first time
and
watched while it built the help topic database on my admittedly slow 166
Pentium. Ok, so my mere 166 Pentium isn’t a screemer by today’s
standards.
What I noticed was that the process slowed down as it progressed. I.E.
At
first it was able to do several thousand topics a second, then about
1000
a
second then it took several seconds to do 1000 topics, then more seconds
per
1000.

My application specialty is data bases. I have written many custom high
speed data bases over the years. This is the classic overhead of
inserting
an index entry into an array that keeps getting bigger and bigger. But
it
should not have slowed down so much in just 35,000 entries (I didn’t
notice
the exact number). A smarter hashing algorithm is definitely needed.

I noticed this same problem when I ported my data bases to V 6. The
biggest
problem I found was that while every single process bound function is
slower
in V6 (as compared to V4) the memmove() function was a real pig. I
re-wrote
memmove() and posted the asm code here (one of these newsgroups, I
forget
which ) several months ago. I really, really, Really, REALLY suggest
that
you incorporate my version of memmove into the general libraries. It
will
speed up everything that pushes data around. My data base application
went
from taking 3 hours to index a 4,000,000 record multi-key data base to
about
26 minutes, with no other change.

P.S.

Found my post, qdn.public.qnxrtp.devtools “OUCH - A LOT ! !” dated
Tuesday,
October 30, 2001 7:58 PM with an attachment. Don’t use the Oct 26 post!
It
had a bug.

\

Hi…
The helpviewer search problems and the generation of the index database have
been revised, but
it didn’t make it into the release.
Adrian

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aeb0l9$oni$1@inn.qnx.com

Using the new 6.2 NC I just went into the Helpviewer for the first time
and
watched while it built the help topic database on my admittedly slow 166
Pentium. Ok, so my mere 166 Pentium isn’t a screemer by today’s
standards.
What I noticed was that the process slowed down as it progressed. I.E.
At
first it was able to do several thousand topics a second, then about 1000
a
second then it took several seconds to do 1000 topics, then more seconds
per
1000.

My application specialty is data bases. I have written many custom high
speed data bases over the years. This is the classic overhead of
inserting
an index entry into an array that keeps getting bigger and bigger. But it
should not have slowed down so much in just 35,000 entries (I didn’t
notice
the exact number). A smarter hashing algorithm is definitely needed.

I noticed this same problem when I ported my data bases to V 6. The
biggest
problem I found was that while every single process bound function is
slower
in V6 (as compared to V4) the memmove() function was a real pig. I
re-wrote
memmove() and posted the asm code here (one of these newsgroups, I forget
which ) several months ago. I really, really, Really, REALLY suggest that
you incorporate my version of memmove into the general libraries. It will
speed up everything that pushes data around. My data base application
went
from taking 3 hours to index a 4,000,000 record multi-key data base to
about
26 minutes, with no other change.

P.S.

Found my post, qdn.public.qnxrtp.devtools “OUCH - A LOT ! !” dated
Tuesday,
October 30, 2001 7:58 PM with an attachment. Don’t use the Oct 26 post!
It
had a bug.