Loading wallet more quickly

[dysconnect]

Is there a way to make nud load more quickly, probably at some costs? I’ve been playing with the source code lately and it’s quite a nuisance waiting for the compiled nud to load again and again.

[CoinGame]

This has been reported by a couple of people, and optimizing the block index loading will be part of the next release. @sigmike may have more info.

[sigmike]

Yes, this should be improved in Nu 2.1.0.

In the meantime, a fast disk and/or a large amount of memory make it load pretty quickly (it spends most of its time loading files, so fast I/O and a big file cache are good).

[matthewd]

I have recently not been able to update my wallet. Previously, if I got a week behind, I could update it overnight

Recently, I got about a week behind, but overnight it barely caught up by one day.

So, I left the wallet updating all week and the block chain has crawled up to about 99.5%, but cannot push beyond that - in fact, it slips back! So, it must be updating slower than the day is passing

Is this due to Nu 2.0, and is it likely to be resolved by 2.0.1?

[mably]

Does this mean that Nu isn’t compatible with low spec hardware like a Raspberry Pi anymore?

[masterOfDisaster]

Maybe it’s necessary to grab a Raspberry Pi 2.
My self-made nud (with libdb5.1…) runs fine on my RaPi2 and is synced.
I don’t know about minting on a RaPi2 with nud, though…

[sportscliche]

Looks like this is my problem as well. I’ve posted more info in the “Nud freezes on startup” thread.

[masterOfDisaster]

Nice: https://bitbucket.org/JordanLeePeershares/nubit/issues/212/switch-to-leveldb
Should help

[JordanLee]

Increasing the speed of the application (especially when loading) and reducing memory usage have already been established as the primary improvements we are aiming for in the Nu 2.1 release as you can see from these issues being tracked in the code repository:

Switch to LevelDB
Application startup takes a long time
Improve memory usage

We are also including a getfeevotes and getprotocolvotes RPC to make fee and protocol votes easily observable.

The 4.0 B&C Exchange release is mostly code complete. Once it is done, the team will quickly code the 2.1 Nu release, and then return to working on B&C Exchange.

Some of the optimizations are still being designed, but I expect we will see major reductions in the time required to open the application and in the memory required to run it.

[sportscliche]

From my perspective, this problem has gotten worse. When the memory demands of the nu client ramped up in late summer, I was no longer able to synch the blockchain on my low spec hardware. (I continue to mint Peercoin and Blockshares on that box without any problems) I migrated the nu client to my main 2 GHz dual core PC, where it consumed about 1/3 of the available 4 Gb RAM.

In the last 48 hours, I’ve lost blockchain synchronization on my highest performance hardware. I have been a minting node on the nu network continuously almost since launch. Regrettably, I can no longer participate and will be offline until the 2.1 upgrade.

[Cybnate]

Not sure if it is getting worse, but it is a problem indeed. I’ve a nu client on one of my servers taking 1.5Gb without blinking. Not good. Only regular restarts can help to mitigate it a bit. Definitely looking forward to v2.1.

[zoro]

the champion is the bitcoin.
after months of running in win7,
bitcoin-qt ~ 3GB
NU ~ 1 GB
i have updated my ram to 16GB so i am ok

edit:
BCE ~ 150MB
peerunity ~ 110MB