I've been experiencing intollerable slowness in both the Windows client and the Web client using version 7.1.1.7329.

Here are some timings:

• Click on any project in the project tree:  19-30 seconds.
• Double-click a feature, defect, or task:  19-25 seconds.

Pretty much anything I clicked on took between 19 and 35 seconds.  Sometimes it took over 80 seconds (especially messing around on the users tab).  I discovered that turning off the filter made things much faster, but STILL slow (7-10 seconds).  So, I decided to examin the tables.  I was shocked to find that the few tables I looked at (Projects, Defects, Features, & Tasks), had NO INDEXES!!! aside from the primary key on the <TableName>ID field.  So, I added my own indexes.

My timings are now:

• When filter is on:
• Click on any project in the project tree:  8-12 seconds.
• Double-click a feature:  ~9 seconds.
• When filter is off:
• Click on any project in the project tree:  1 second (or less).
• Double-click a feature:  5-8 seconds.

Note that I have very few items in my database:

• projects = 70
• defects = 12
• features = 111
• incidents = 0 

I got these numbers by running the following queries:

select count(*) from projects

select count(*) from defects

select count(*) from features

select count(*) from incidents

I highly recommend to axosoft to exam how your code is querying the data and make appropriate indexes.  Generally, an index for each foreign key and an index for any "order by" clauses.  I added indexes on the tables with ProjectID + (whatever I filter by), so I had about 5 or so indexes per table on those 4 tables.

I also noticed that the function fnProjects does a "LIKE" filter on the "Path" field.  That's going to be very slow, especially since there's no index on Path and even if there were one, it couldn't be used because of the "LIKE '%" comparison.  You might want to try something like having a ParentProjectID field and if the ProjectID passed in is not null, do a recursive query (SQL Server 2005 only though).  I don't know if it'd be faster, but it'd be worth experimenting with.  You do need something for the tree structure to be indexed.  Also, search all your functions, stored procedures, and views for any use of the "LIKE '%" comparison and see if you can figure out a way to accomplish the same thing in a way that takes advantage of indexes... even if it means adding new columns.  You even might try adding a new child table.  Maybe something like a one to many from Projects to this new ProjectPaths table.  The ProjectPaths table would have many entries for one project.  Each entry for a project would have a ParentProjectID, then a number following that, indicating the order of inheritence.  Of course, the child table would use indexes (ProjectID + ParentProjectID + InheritenceOrder).  There wouldn't be any textural, brute force searching and it'd all be indexable.... just some ideas.

This is an AWESOME product, but it's WAAAAAY too slow.  At the very moment that the speed issues are taken care of, I'm going to press hard for my employer to purchase a bunch of licenses.  We have about 19,000+ desktops (obviously, not all developers).  I can't recommend it yet because the slowness is severely impacting my productivity.

Good Luck!