Having moved to 764 we have found developer studio painfully slow.

Here is a very simple test fex that illustrates this point. It creates a directory in approot and populates it with 500 fexes.

-* File slowds.fex
DOS MD &APPROOT|\SLOWDS
-RUN
-REPEAT LOOP FOR &I FROM 1 TO 500
DOS ECHO -TYPE HELLO > &APPROOT|\SLOWDS\TEST&I|.FEX
-RUN
-LOOP

If you run this and then logoff your ds environment and log back on again if you have the full unrestricted version then when you re-open the window slowds directory will be there.

If you go to slowds and open the .fex window and then right click and select 'refresh' I get the following timings.

wf 7.1.6 takes 3s to refresh
wf 7.6.4 takes 10s to refresh

I would be interested to see what timings others get.

Here are some more links on the subject.

Subject first raised under 762

IB think it might be virus software but why 716 not affected?

Why oh why?

Surely the timings are only really useful when applied to real life situation. I'm now using 7.6.4 alongside 5.3.2, 5.2.7 and 7.6.1 and I'm very, very impressed.

Most impressively for me is that extremely complex MAINTAINs run without recompiling under 7.6.4 even though they were written under 5.2.7

Let's hear some positives rather than the usual negative aspects raised on the FORUM.

Happy parallel testing....
P

P,

Hammo1j relates a problem that he is experiencing in Dev Studio and you reply that a Maintain runs fine? Not really the same animal are they? .. and surely his experience is a "real life situation". He is obviously developing and this is impacting his development experience?

I agree with you that some posts have an air of negativity about them, and some should be raised direct with IB support especially when it is likely to be an enviromental effect over a mere question on how other contributors have resolved a particular coding problem or requirement.

However, it is an "open" Forum and IB are inviting comments such as this. If IB are concerned about a negative view that appears to be arising, then they should try and approach the poster to see if they can help resolve the issue and perhaps encourage direct reporting of such problems?

Just my halfpennies worth.

T

quote:

I would be interested to see what timings others get.

Hammo1j,

I'm not seeing the slow downs you are.

Windows 2003 Enterprise Edition SP2 2GHz 1Gb Ram (running inside vmware)
VirusScan Enterprise 8.0.0 patch version 10
Dev Studio Ver 764 Gen 11142007 Package ID 764_111507

Timings to do refresh of WebFOCUS Environments/localhost/Data Servers/EDASERVE/Applications/slowds/Procedures
3.45, 3.41, 3.47, 3.37, 3.43 (average 3.426 seconds)

Note: WF full reporting server also installed on same machine

MS Windows XP Pro Version 2002 SP2 2GHz 3.25Gb RAM
VirusScan Enterprise 8.0.0 pathch version 11
Dev Studio Ver 764 Gen 11142007 Package ID 764_111507

Timings to do refresh of WebFOCUS Environments/localhost/Data Servers/EDASERVE/Applications/slowds/Procedures
2.91, 2.90, 2.78, 2.90, 2.98 (average 2.894 seconds)
Timings to do refresh of Projects on localhost/slowds/Procedures
1.34, 1.47, 1.33, 1.31, 1.23 (average 1.336 seconds)

The numbers you are getting may be anti-virus related or possibly network - is the apps dir on the same local machine? Either way you probably should open a case and get IB to have a look at the issue. There might be some traces that will show where the performance hit is.

cheers

Stu

Stu

Thank you very much for taking the trouble to provide me with these figures.

I will raise this as a case but it the meantime I notice that the versions of McAfee you are running are 2 minor releases ahead of mine.

Here's my virus details

so I will ask our desktop staff for the latest release and see if that improves matters while I am waiting for the results of the case.

As you mention these figures are same machine to same machine and ours are via separate server
and wfclient machines so I might temporarily rig a test to see what results I get on a local server.

Once again thank-you for taking the trouble.

Another point of interest is that ds seems to be paged out as soon as you lose focus on it.

Using sysinternals excellent replacement for task manager, you can view the working set of focshell.exe as it is executing by selecting the properties window of the focshell process.

If you switch to another window from you instantly lose physical memory and it has to be paged back in again when you switch back to the ds window.

I tried this with internet explorer and this did not happen. There was always a delay before physical memory started to be taken from the process. To check that Microshaft weren't up to their usual trick of letting the os favour their own products, I checked a third party product and there was not instant loss of memory.

I checked about c++ applications and it seems that it might be a compiler switch that causes this behaviour.

Will pass this behaviour on when I raise the case but would be interested to see if anyone else has experienced this where ds is 'swapped out' quicker than other applications.

I have just checked on 716 and there is not the immediate swapping behaviour that you get on 764 so it could go some way to explaining the performance difference.