AmiBroker get stuck while Saving data before closing application. Other performance issues

AmiBroker
1

Hi
I have been facing up with this problem as screen below in many times.
You can notice "?????" on Save dialogue. It takes longer than usual to process and close app subsequently without updating the database.

abstuck

abstuck2

I try to find out something wrong in window log; unfortunately, there is nothing to indicate about this error. whether Error or warning or critical in window log.

abstuck3
I would like to make sure whether the entire database of me is intact.
and What is the best way to fix this problem?

2

@technqvi here below a suggestion based on your last screenshot that shows a low power condition.

Actually, I never experienced this issue, but maybe in your advanced power saving settings you have some condition that will stop the hard-disk frequently, and when you try to save the data it takes a long time to restart it. (The issue may also due to other reduced performance devices).

Just to see if something is related to the power saving settings, for a while, try to disable them entirely and see if it happens again. If the issue disappears then re-enable them progressively (until you find the culprit), otherwise at least you can exclude a potential cause.

In any case, before doing that, I recommend performing an error-checking (ChkDsk) operation on the disk to verify the integrity of the file system, and then, if there are no issues and the fragmentation status is over 10% follow it with a defragmentation.

3 Likes
3

This means that file save takes long. Saving in AmiBroker is done using simple fwrite() call which is super fast under normal conditions. It if takes long, there is something wrong with your computer. It can be because of Antivirus. Antiviruses can slow down the system to the crawl. Exclude data files from antivirus scan. Second thing your hard disk may have developed errors. Run checkdisk as advised. You might have run out of free space. Also if you are using SSD check if you have firmware updated (for example I had Crucial disk that was stuttering and only firmware update fixed it).

2 Likes
4

Well in my old case, I had an HDD before and apparently the C:on the physical disk was somehow worn out. Long lives SSDs :smiley:

Generally, the OS tends to max read/writes in very specific locations over long period of time for eg. where the page file is located etc.
HDDs get thrashed, (page file thrashing eg) a lot in many cases especially when the partition is small like 100-200GB or filled up 70% etc

The HDD wont crash but read/write to those sectors is painfully slow.

You can use tools like crystaldiskinfo and crystaldiskmark among others.
If you have multiple partitions, use crystaldiskmark to test read/write speeds to each one and compare them.
This is how I solved my problem.
Do a lot of Randoms read/writes with large and small files using it.

Links: https://crystalmark.info/en/software/crystaldiskmark/

1 Like
5

Many thank for all to recommend me.
I think that, it is related to the low battery along with the anty virus program (window defender security)
Basically My Database has been excluded from Window defender already.
Apart from that I run checkDisk as your recommend. It is ok sofar.
disk

I plan to buy new laptop for Amibroker development.

The following is a few questions to ask you

  1. Is SSD recommended for a new laptop? please refer link to more additional info about it.
  2. what suitable core CPU prefer? i5 or i7
  3. Are there any link reference to software /hardware specification to compare between dev machine and production machine
6

Just a few pointers from my experience.

Q1. SSD
In this day and age its definitely a yes. The slowest component in a PC is HDD. SSDs are faster by 10X and more.
Current era talks about M2 SSDs and NVME SSDs, so 2.5' SATA SSD are also phasing out.
Reliability wise, it was long ago they had issues, now very good.
Brand: I prefer Samsung ones, something with VNAND having edge. RAMs I prefer Crucial or Corsair.

Q2. CPU
Depends very much on your Load, but if you will have windows 10, there's alot of bloat nowadays, including how heavy the browsers have become, go for i7.

If you will only run AB, then in that case i5 works smoothly, but will vary depending on load put by AB.
AB user AFL can be programmed to put infinite load on a system :smiley:

Q3. You can first narrow down to your expected Load, and decide if its a laptop or a Custom built PC.

1 Like
7

For what it is worth, last time I dusted off my oldest notebook with Windows Me (from 1999) with whooping 160MB of RAM (yes megabytes) and 300MHz processor and AmiBroker 6.0 32-bit is running just fine on that machine. So you really don't need super powerful PC for AmiBroker (unless you kill it with your own formulas :-))

5 Likes
8

Information presented in this post might be useful for the new users, or those who would like to take full advantage of AmiBroker's performance. For example it shows, why it's a better idea to use SumSince() whenever possible instead of Sum() or Cum() etc.

It is because of the fact, that most programs usually become bigger and slower with each new release. On the contrary, AmiBroker is becoming faster and faster.

Here are some examples of the changes implemented in previous versions, which make code execution faster. These are excerpts from Read Me files attached to each AB release: www.amibroker.com/devlog/ :

v.6.22
64-bit: Migrated all code to new compiler VC++2017 which seems to produce better code for x64 resulting in 30…50% speed improvements for many AFL functions. The only negative seems to be much bigger runtime libs
64-bit: AFL: Sum() function 2x faster
64-bit: AFL: Max() and Min() functions 8x faster
64-bit: AFL: Ref() function 2x faster
64-bit: AFL: MACD(), ROC(), StDev(), LinearReg() and many other functions faster by 30-50%

v.6.21
AFL: Decreased memory fragmentation when user changes type of variable from array to scalar and back thousands of times

AFL: RequestMouseMoveRefresh( ) – request formula execution / refresh when mouse is moved INSIDE given chart pane (it only triggers for ONE window under the cursor)

v. 6.13
AFL: MA function made upto 2 times faster , StDev function made 20% faster , Correlation made 40% faster

v. 6.11
AFL: MxFromString was slow on very large matrices (>100000 cells) due to poor performance of strtod function from Microsoft C runtime. Now MxFromString does not use it and is even 1000 times faster on 100K+ cell matrices (5ms vs 5second)

ASCII importer can now be even 20 times faster when importing NEW (non existing) data that were oddly sorted (like for example in reverse order - descending dates instead of ascending).
ASCII importer is now twice as fast when updating already existing quotes thanks to using in-house code instead of msvcrt functions.

When there were thousands of files in "Formulas" folder opening editor for the first time could take some time. Now this time is significantly reduced.

v. 6.07
Compression of persistent static variables (and arrays) implemented - can save as much as 90% of disk space and memory

v. 6.06
AFL: new function SumSince – a fast sum of array elements since condition was true, works like Cum( array ) – ValueWhen( condition, Cum( array ) ) or Sum( array, BarsSince( condition ), but much faster.
According to my measurements new SumSince is indeed many times faster than Sum().

AFL: Variable period Sum() performance improved significantly when period changes +/-1 on bar by bar basis

AFL: new function GfxFillSolidRect ( x1, y1, x2, y2, color ) – it is fastest method to fill solid rectangle with single color (faster than GfxRectangle)

v. 6.02
Faster composites by means of new function StaticVarAdd. Single threaded StaticVarAdd may be twice as fast as ATC. With 8 threads running StaticVarAdd may be 4x as fast. StaticVarAdd( “name”, value, keepAll = True, persistent = False ) – an atomic addition (interlocked read-add-write) operation for static variables.

v. 6.0
Full Matrix support

v. 5.91
Analysis: CSV Export speeded up 100+ times . Now exporting large files takes seconds instead of hours. Export speeds on ordinary hard disks > 80MB/sec

v. 5.90
AFL Engine: custom memory allocator does not use Microsoft runtime lib for reference tracking anymore. Result - complex formulas with lots of loops and OLE (especially low-level custom backtests) run upto 3 times faster in 32 bit and 4 times faster in 64-bit

Execution speed improved by factor > 2x for AFL functions: MACD, Signal, CCI, Sum (variable period)

v. 5.88
New Analysis: QuickAFL finally implemented. To turn it on go to Settings and check “Use QuickAFL” box. Gives very significant speed-ups (>2x) when range is smaller than “All quotes”

v. 5.82
AFL: CCI function speeded up by 50%

v. 5.80
AFL: Co-ordinates can now be given in both pixels and bar-price mode GfxSetCoordsMode - speed improvements (upto 3x)

etc ...

For the reasons above, whether someone wants to achieve full performance on the latest, sophisticated workstation or is very attached to his/her "Millennium Edition" computer from the year 2000 :wink: should be using the most recent, not the oldest version of AmiBroker...

4 Likes