CincomSmalltalkWiki: Store speedup tips

"From the defunct UIUC VW Wiki"

I started to gather some discussions here, please edit/cut for readbility! TIA -- RH

I had too long delay (15 minutes) when load bundle in vanila image. My database is Oracle 8.0.5.
After tuning, loading time was 55 sec. Some of the steps are very evidient, and not tuning at all, but they can stay as reminder for those who using store.
1. Profiler bring some point: 74% eats database access.
Gather Oracle statistics. It is so evedient but I forgot to analyze(process of gathering statistics) my tables and indexes. System tables (user_tables and user_indexes) reveal that tables and indexes was not analyzing at all. After full analyze(compute statistics) of tables and indexes loading in vanila image take 5 minute (~300sec).
2. I wanted to track db issue father. So I founded the slowest query. Almost all access to db eat 1 query:
```
SELECT
    *
FROM store.TW_MethodsAndSourcesView
WHERE  packageRef = "--some, possible not existing, package id--"
```
The problem with this query was full scan of TW_Methods table. Quick look at indexes on primary key(and explain plan later prove it) reveal that two columns index on TW_Methods primary key did not work. After adding index on TW_Methods.packageRef loading take 210 sec. This index don't have negative impact on post.
3. At this point profiler show whery interest point: 40% is updates of RB lists after methods compile. I close RB :) Loading time droped to 110 sec. So, keep RB closed.
4. Profiler say: 63% is writing to .cha file during compilation. Andrei N. Sobchuck track this down. The real problem was that at any method compile writes to .cha file occur. He propose solution - don't write changes every time, write once at end. Here is solution (with my mud translation): "First of all I'm copy method ClassDescriptor>>compile:classified:notifying:environment: to: ClassDescriptor>>compileForStore:classified:notifying:environment: And changed "safety: true" to "safety: false" At end I invoke compileForStore:classified:notifying:environment: in Store.Method>>loadAsNewIn: (instead of compile:classified:notifying:environment:) "
And we have excelent time - 55sec!

We have a different solution: we run our builds on a RAM-disk. I use www.ramdisk.tk. The speed increase is about the same, but you still have the benefit of the .cha file (for instance, incorrect ordering on some tricky parts of our app can cause VW to loop / crash - the .cha file at least shows the last change before the problem). Of course, a RAM-disk isn't a good idea for general use, really just for builds.
Some of the above patches are available from an unrelated donation in the public repository as package 'Store-Speed patches'. Please contribute and republish!

One thing I do is change
```
Store.Package>>itemCount

        ^1
```
This removes the ability of the progress dialog to display very much useful when loading, but computing the item count, particularly if you have nested bundles, takes enough time that I'd rather have it load faster than tell me how far along it is.

We had the problem, that the cha-file is very big. To solve this, I parcle out the Bundles to a directory in the network, to which all developers have access. (I don't publish the Bundles!!!). After this action, the source-code pointers of the Bundles point to the pst-files generated by the out-parceling. At last, I condense the changes and the cha-file shrinks to 1 kb. After this, all developers get theirs source-codes by only one file in the network. Only the code they change is listed in the cha-file.

Linux/X11 users can be bogged down by excessive cursor changes during load. These seems somewhat less of a problem since VW7.1 but for those that need it there is the package ThrottledCursor
Store PostgreSQL Speedup