Slow performance seen during checkinView operation

QUESTION:

While looking into some possible performance issues using the
debug/Show_Timings.jsp page, one method we are spending time in is in the
com.waveset.ViewMaster.checkinView method. 

I've also noticed on this timings page that we are doing a lot of File I/O
operations. 

Are these two connected somehow?

ANSWER:

The performance of ViewMaster.checkinView is extremely variable. It depends on
the type of view you're using, the forms you're using, and the task that gets
launched. In general, checkinView will do the following things for all view
types. 
  
  1) run the Expansion expressions in the Form 
  2) do view-specific "refresh" processing 
  3) convert the view into one or more repository objects 
  4) launch a task, often a workflow task 
  
File I/O doesn't normally happen unless you are using a "local files"
configuration of the repository. If you are, then you may see I/O during steps 3
and 4. A local files repository is much slower than other configurations, it is
useful only for testing and demos. 
  
File I/O can also happen if you have one of the tracing options turned on.
Workflow and XPRESS trace in particular can really slow things down, check
Waveset.properties to see if any of these are set to true: 
  
  exception.trace 
  xpress.trace 
  form.trace 
  workflow.trace 
  workflow.consoleTrace 
  workflow.fileTrace 
  provisioner.trace 
  task.scheduler.trace 
  
Class and method trace enabled in the debug pages can also slow things down. 
  
If you are not using a local files repository, and do not have trace enabled,
then the only place file I/O should be happening is in your <Expansion>
expressions in step 1. Look at the Form and see if any of your Expansions invoke
custom Java classes that might do I/O or query a database. 
  
The view-specific "refresh" in step 2 is dependent on the view you are using.
Refreshing the WorkItem and Process views has practically no overhead.
Refreshing a User view is rather complicated. It generates a lot of garbage and
is not particularly efficient, but is usually not significant compared to the
overhead of accessing the repository and the resources. This may become more
significant if there are a lot of concurrent users. 
  
In step 3, we usually write at least one repository object. Depending on what
the underlying database is and the load on it, this may be fast or slow. Usually
it is relatively fast. 
  
Step 4 is where most of the variability in performance lies. The task is usually
run synchronously, meaning that it will execute to completion in the request
thread. For a User view workflow without approvals, this means we may do
provisioning which is usually the most expensive part of checking in the User
view. If there are approvals, we will execute up to the first approval and
suspend the task. This is usually relatively fast unless you have modified the
workflow to run database queries prior to approvals. 
  
Checking in a WorkItem view does not launch a process, so it should always be
fast. 
  
Checkin of a Process view will launch an arbitrary process, so performance is
dependent on what that process does. If the TaskDefinition has an execModeof
"async", then it will launch the task in the background and the checkin should
appear fast. If execMode is synchronous, the task will execute in the request
thread, if it is something like a report or resource scan it could take a long
time.