By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,971 Members | 890 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,971 IT Pros & Developers. It's quick & easy.

Object reference terribly slow with certain user profiles

P: n/a
Hi, group!

Here is some interesting problem:

Our company has developed a large VB6 application that runs very smoothly on
most environments.

However, all of a sudden one of our customers (unsing WinNT SP6) experienced
a dramatic
performance drop. We investigated, and it turned out that it depends on the
user that logs on.
Only certain users with user profiles have those performance troubles with
our software.
After further investigation it turned out that referencing propertys and
methods
of class instances through unspecific object variables (declared "as
Object")
ist over 100 times slower than normal.
For example, this works fine:

Dim o as MyInterestingClass
Dim i%
Set o = MyInterestingClassInstance

for i%=1 to 100
o.DoSomething()
next
This, however, is more than 100 times slower:

Dim o as Object
Dim i%
Set o = MyInterestingClassInstance

for i%=1 to 100
o.DoSomething()
next
Okay, we all know that using unspecific object variables can slow things
down, but not 100 times!
And, as I said, the stunning thing is that only certain users with user
profiles have the problem.

Has anyone heard of such a problem or knows the possible cause of that? How
can user profiles
affect VB6 .EXE files in that way? BTW: We tried to compile to native code
instead of P-Code -
it made no difference at all!

---

Helmut Hoerner
he*******************@hhsoft.com
(pls. leave out the nospam part if you want to send me an email)
Jul 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Asperamanca" <as*********@yahoo.com> schrieb im Newsbeitrag
news:3b**************************@posting.google.c om...
Some rather obvious suggestions:
Do you use the newest VB6 service pack (SP 5)?
Try to turn off code optimization if you use it, in my experience it
makes more trouble than it's worth.
Have you ananlyzed the differences between there users?
*) Different rights? Does the application have to check the user's
access rights somehow?
*) Different network access settings? If the application accesses a
network, this can slow things down
*) Different applications running? Is enough physical memory
available?

Robert


Hi Robert,

thank you for your suggestions.

- With "Compile to P-Code" there are no optimization settings, and as the
problem occures with "P-Code" as well as with "Native Code" I have little
hope in the different optimization settings.
- Actually, for some deployment reasons we still stick to VB6 SP3. Of
course, you are right, we should investigate if SP5 could fix the problem
- As for the network access: The problem has *nothing* to do with file or
network access. It's simply referencing methods and variables through object
variables.
- Physical Memory ist okay, and there seem to be no difference in running
backround tasks for the different users.

Our latest guess is that with the user profiles someting in the "current
user" part of then registry could get messed up (probaply too many
registered ActiveX objects, or something like that).

Regards,

Helmut Hoerner
he*******************@hhsoft.com
(pls. leave out the nospam part if you want to send me an email)
Jul 17 '05 #2

P: n/a
As I see it, the only difference is early time binding vs late time
binding. The only additional chore for late time binding is finding
the actual address of the function you want to call from a table. I'm
not entirely sure, but I think in VB6 classes are just COM objects,
internally, so this task would be up to the OS (please correct me
someone, if I'm wrong).

Therefore, my best guess is that NT 4.0 is a bit screwed up (which is
a safe guess anyway, from my experience). Of course, that wouldn't be
a lot of help.

My best suggestion is trying to avoid the generic Object. That can be
though, and sometime outright impossible, I know. Maybe try if using
an Interface helps - an Interface where DoSomething is defined, which
is implemented by the
MyInterestingClass. Then, you wouldn't have to declare the variable as
Object, but rather as MyInterface, and late time binding should not be
necessary for DoSomething.

Hope that helps

Robert
Jul 17 '05 #3

P: n/a

"Asperamanca" <as*********@yahoo.com> wrote in
news:3b**************************@posting.google.c om...
As I see it, the only difference is early time binding vs late time
binding. The only additional chore for late time binding is finding
the actual address of the function you want to call from a table. I'm
not entirely sure, but I think in VB6 classes are just COM objects,
internally, so this task would be up to the OS (please correct me
someone, if I'm wrong).
I don't know about that for sure, but the problems we have seem to suggest
that you are right. Obviously the the task *is* up to the OS, or how else
could the performance suddenly get worse?
Therefore, my best guess is that NT 4.0 is a bit screwed up (which is
a safe guess anyway, from my experience). Of course, that wouldn't be
a lot of help.
Yep.
My best suggestion is trying to avoid the generic Object. That can be
though, and sometime outright impossible, I know. Maybe try if using
an Interface helps - an Interface where DoSomething is defined, which
is implemented by the
MyInterestingClass. Then, you wouldn't have to declare the variable as
Object, but rather as MyInterface, and late time binding should not be
necessary for DoSomething.


Actually, today we have tried just that - and you know what: It helps!!!

Still, it's very annoying and a lot of work, but at least we have a
workaround now! Thank you very much for your time and your suggestions!

---

Helmut Hoerner
he*******************@hhsoft.com
(pls. leave out the nospam part if you want to send me an email)

Jul 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.