We are trying to resolve some performance issues at a remote site.
One thing that we suspect could be causing the performance problem is page ghosting.
Is there some way to see if the pages that are being called are ghosted?
In my experience, the ghosted/unghosted thing is a total SharePoint myth. If you're having significant performance issues with a page, I sincerely doubt that this is the problem. I'd look more at what Web Parts are on the page and what you're asking them to do.
Solving performance issues in SharePoint by second guessing what the problem could be could be a very long and tedious process.
What you should do is give the site a thorough check-up for issues that could affect performance (and yes closed web parts is one on a probably very long list).
faulty NIC. I have seen this wreck performance on an otherwise well performing site.
how large is the footprint of your pages? If you need to load tons of
CSS, JS and images by every request
(without caching them) this could
kill performance as well.
This was a few of the issues i would consider, again depending on what kind of patterns for bad performance you experience (you dont describe this in your question).
I asssume by 'called' you mean by the browser.
If you just want to see if a given page is customised then you can look at the pages in SharePoint Designer as this will show you quickly which ghosted pages have subsequently been customised.
Of course if you need to do it via code then this is not a viable approach.
Have you checked out the site with Fiddler to see what is happening under the covers?
As Marc said the issue may not be the ghosted/unghosted status of the page but...if you do want to check the status of the page then SharePoint Manager is a really useful tool for looking at properties of SharePoint objects. This should save any time writing code to do the check and if the page is unghosted then 'customizedpagestatus' will show customized.
As Marc said above, check the number of web parts and what they are doing. Especially check if there are a large number of 'Closed' web parts hiding behind the scenes from power users not understanding the difference between Delete and Close. They are not visible but will continue to consume all those resources. Almost every time I assist someone with a performance issue on a site, its due to >= 10 Closed web parts.
Another issue to check and this may seem strange is to find out if you have custom built webparts that have code. It is possible that some of them may not be properly releasing the resources they used. This is just an addition to the other points already mentioned.
My 5 cents: If that's an option at all, you could check the ASP.NET trace timing to see the shares of each control rendering or not rendering in the page's control tree. See web.config/system.web/trace for the application pool in question and add trace.axd in the url (or set the pageOutput attribute to 'true' for the trace element in the web.config).