Compound Enumeration (that's a term I just made up, forgive me)

Sorry should be nano seconds, not micro seconds.

Here's your solution again, optimized, running at 15000 nanoseconds on my machine compiled without array bound checks, integer overflow checks, floating point overflow checks etc.

Code:

---

Sub Main()
    Dim start@, finish@, freq@, total& 'QPC
    Dim pieces&(9)
    Dim dblTemp#, s&
   
    Dim dblCode As Double
    Dim aFurniture(9) As String
    Dim aPrimes(9) As Integer
    Dim x As Integer
    Dim y As Integer
   
    'Set up variables
    aPrimes(0) = 2
    aPrimes(1) = 3
    aPrimes(2) = 5
    aPrimes(3) = 7
    aPrimes(4) = 11
    aPrimes(5) = 13
    aPrimes(6) = 17
    aPrimes(7) = 19
    aPrimes(8) = 23
    aPrimes(9) = 29
   
    Randomize 'generating order
    For n = 0 To 9 '//// Pieces generated before loop
        pieces(n) = Int(Rnd * 10)
    Next n
   
   
   
    QueryPerformanceCounter start
   
    For s = 1 To 10000
        dblCode = 1
        For x = 0 To 9 '//// 3) inside the timer
        dblCode = dblCode * aPrimes(pieces(x))
        Next x
        'Deconstruct dblCode
        n = 0
        For y = 0 To 9
            For x = 0 To 9
                dblTemp = dblCode / aPrimes(x) '//// Saves 2 floating point divisions
                If dblTemp = Int(dblTemp) Then
                    dblCode = dblTemp
                    pieces(n) = x '//// Adds back to order list instead of performing string concentration
                    n = n + 1
                End If
            Next x
        Next y
    Next s
   
    QueryPerformanceCounter finish
    QueryPerformanceFrequency freq
   
    total = Int(CDbl(finish - start) / CDbl(freq) * 100000)
    MsgBox total & " ns"
End Sub

---

Let's just leave vb's unicode strings because 99% of the time cpu will be working on them instead of doing the important algoritm ok?

Aah - yours is 500x times faster! Well at least you have some sensible modifications to my method. So it comes: I concede defeat.

Can you do a detailed explanation of ure code plz keds??

Well sure, details details and more details ;) Mostly it's about low level efficiency, but vb isn't the right language for speed although you can at least get some by understanding what the cpu actually does with the code you compiled.

First some details on the api's I used.
Querryperformance - This is probably the most accurate timer available
I though looped the algortim 1000000 times and multiplied the result with 1000 to get the result in nanoseconds.
Copymemory - copies binary data with specified length from specified source to destination.

CopyMemory number, b(0), 5&
CopyMemory b(0), number, 5&

I use it here to copy over the binary contents of a byte array to a currency datatype. Doing operations on a currency datatype (64 bit integer) is very inefficient about 17 times slower than on longs (32 bit integer). I am forced to use Currency, or Double or another 64 bit datatype as 32 bits isn't enough to describe 10^10 possible orders. This isn't mainly why I used copymemory.
As I have 64 bits to spend, I gave each furniture type a nibble (4 bits) I could have given each 10 possible combinations instead of 16 to constrain memory usage, but for speed efficiency 16 is better. One byte will be assigned two furniture type amounts, so by using a byte array instead of a single number, you avoid unnessesary bitshift, or in this case with vb: multiplication, a lot slower operation than addition. I save 50% of the time spent on multiplications by adding the low nibble to the hi nibble*16 to produce the byte, this illustrates the byte and the data components:

say we have

2 Tables: 10 binary [ 0010 ]
8 Chairs: 1010 binary [ 1010 ]

The byte:
2 * 16 + 8 = 40
[ 0010 ] * [ 1 0000 ] = [ 0010 0000 ]
In C++ this could have been done with bit shifting: 2 << 4; which is extreemle faster than multiplication
[ 0010 0000 ] + [ 0000 1010 ] = [ 0010 1000 ]

[ 0010 1000 ] (40)
And there's the byte, storing both the amount of tables and chairs. To retrieve the value an unexperienced programmer would use x mod 16 to retrieve the low nibble, the amount of chairs. I know that modulus is as slow as division for that matter, instead I use bitwise AND to flag off the hi nibble:
40 and 15 = 8

Code:

---

    [ 0010 1000 ]
and [ 0000 1111 ]
------------------
    [ 0000 1000 ]

---

To retrieve the hi nibble I divide by 16, In C++ i would have shifted right 4 bits. To at least have some performance I do integer division \ not floating point / which is slower, especially when performed on integers. Not only that, When I do floating point division I will get unwanted decimals, so I would have to use Int() which additionally causes extra performance loss, so when you do
Int(X/Y), replace it with X\Y.

The final byte array might look something like this:

[ 0010 1000 ][ 0101 1100 ][ 1100 0001 ][ 0000 0001 ][ 0000 0110 ]

5 bytes for 10 furniture types. A Currency is 8 bytes but that doesn't matter, I copy over the data and the Currency will look like this:
[ 0010 1000 ][ 0101 1100 ][ 1100 0001 ][ 0000 0001 ][ 0000 0110 ][ 0000 0000 ][ 0000 0000 ][ 0000 0000 ]
which is 573148354982.7072
The reverse process is just copying back the 5 hi bytes in currency to the byte array and perform integer division and bitwise AND on them as shown above.

kedaman - you seem to be the guy to talk to when it comes to timing things, so can I pose the following problem...

I have a FORTRAN DLL and a FORTRAM COM object that implement the same functions, and I started a VB test application to try and test the function runtime differences. It works fine except that the time taken to execute a loop of DLL / COM functions seems, weirdly, dependent on how many of the DLL / COM functions I call in my test loop. Can you think of a reason why this might be so? Also, I was sort of expecting one implementation to consistently outperform the other, but, apparently, sometimes the DLL is faster and sometimes the COM object is faster... again - any ideas?

Timing and testing is very problematic in windows environment, DLL should beat COM but the differences won't be noticable unless the contained functions performance is close to 0. Even with some differences the result values will jump depending on what the system does at the moment resulting in very inaccurate results.