nw.js preview and export build performance difference

I just tried nw.js RC4 and long story short, I'm seeing a significant performance difference between preview and final builds on my test laptop. Contrary to what I expected, the game runs faster (as in perfectly smooth) in preview but get the same kind of jerky lagspikes we've seen in earlier nw.js versions for win32/win64 export builds.

Laptop in question:

i5-5257U — ghz

intel iris graphics 6100 (newer integrated chip)

8 gig ram

Windows 8.1 64-bit

So, nw.js export builds seem to be bad news for integrated chips somehow while preview builds are doing fine. Ashley could this be a texture atlas/fillrate thing and if so, is there anything that can be done to optimize it?

As ever, there is little I can offer without seeing a .capx example. Export should actually be more efficient than preview, because of all the export-time optimisations that are applied.

Fair enough. Right now I was really just trying to explore whether or not there was an obvious explanation for it, like several large sprite sheets overloading fillrate where loads of separate sprite frames wouldn't or something like that.

OK, on my embryonic platform game, at the same re-spawn position with only some background bullet effects taking place...

nw.js 32 bit preview: 48% cpu

nw.js 32 bit export: 39% cpu

nw.js 64 bit export 61% cpu

It's illogical....

Could this be related to the problem of "ghost processes" being left behind, hogging resources in the background so when you played the final export it was slower? If so the newest C2 beta says it works around that problem, so try that if you haven't already.

Hmm, task manager gives me roughly the same cpu usage for preview and export, and the processes terminate right away when I quit. Colludium How did you measure cpu usage?

I have a debug text object that I use to display cputilisation, memory use etc.

So, I tried again this time using r225 and the v13 rc4 nwforc2:

Preview: cpu 36%

export win32: cpu 36%

export win64: cpu 43%

With this later version of nw.js I'm not convinced that there are significant differences now (although I have no idea why x64 should use more cpu).

Of note, if I run an export and then run the preview, something in local storage causes a conflict and the preview crashes to black screen on start (and then won't close down). A memory wipe fixes this....

OK, on my embryonic platform game, at the same re-spawn position with only some background bullet effects taking place...

nw.js 32 bit preview: 48% cpu

nw.js 32 bit export: 39% cpu

nw.js 64 bit export 61% cpu

It's illogical....

I've always had much worse performance with 64 bit export so I've stuck with 32 bit.

I delete the 64 bit NW folder, so the preview is using 32 bit as well, and I get the same performance preview or export.

It seems pretty obvious, but 64-bit NW is intended for developing on a 64-bit system, while 32-bit NW is intended for developing on a 32-bit system.

It seems pretty obvious, but 64-bit NW is intended for developing on a 64-bit system, while 32-bit NW is intended for developing on a 32-bit system.

If my system wasn't a 64 bit i5 then I would not have been able to test it, I suspect. Perhaps there are benefits to the 64 bit version that are not being accessed by c2.... but if the 32 bit export is way better on a 64 bit system for us c2 devs then I don't see the point of having anything else...

I don't understand either why the 64bit version uses more CPU. But as far as I know, the 32bit version will not be able to use more than 4GB of memory.

It seems pretty obvious, but 64-bit NW is intended for developing on a 64-bit system, while 32-bit NW is intended for developing on a 32-bit system.

My system is 64 bit, OS and CPU.

64 bit NW always runs worse. By a lot.

It's not like this in other games.

The way I see it all you really get out of 64-bit is lower compatibility. And no 4 GB memory limit. But I don't think any of us will make an asset behemoth so big it blows that budget anyway

In any case, I think I should make a bug report out of this. Ashley: Is it okay to PM you a .capx soon-ish?

Cpu isn't the thing to worry about.

Fps is.

But a high cpu use tends to correlate with frame drops. Just to be sure, I repeated my tests and added a dropped frame counter (running test for one minute, the counter ignores the first 10 secs because they are usually terrible):

Preview win32: cpu 35%, dropped frames: 4

Export win32: cpu 33%, dropped frames: 5

Export win64: cpu 41%, dropped frames: 17

So, IMO, win64 wins the "not useful" export competition.