HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Shipped: Domino Designer 12.0.2 release supports the 64-bit Designer Client.
https://help.hcltechsw.com/dom_designer/12.0.2/basic/wn_64bitdesignerrelease.html
Please drop Eclipse all together. Bad decisions should not be kept.
Personally, I use:
vmarg.Xmx=-Xmx768m
vmarg.Xms=-Xms128m
vmarg.Xmca=-Xmca512k
I once found an IBM article about the VM memory settings which stated that having the startup not too large (128m), so the limit is reached during startup, at which time compression occurs which is must costlier to perform when done later when the heap is much more populated.
The reason for the 768m is that it lessens the chance of the 32-bit heap bumping over 2G, which will hard crash the Notes client.
Yes, something needs to be done with the Domino Designer, but "make it 64bit" alone wont fix it.
I disagree on this. Designer should be a regular Eclipse-Plugin written in 100% Java. This way anyone could decide to use 32 or 64 bit, whatever she likes.
@mac
there are two ways.
The first update Eclipse in Domino Designer and make it faster (this would not throw away all the components and the great work done for XPages)
The second is to abandon Eclipse and think of something else (but what?) And to support the legacy part (forms, views, agents, etc. ..) that the XPages part
I set vmarg values like below, but sometimes still slow, especially, when I edit a heavy custom control.
<Notes program dir>/framework/rcp/deploy/jvm.properties
vmarg.Xmx=-Xmx2047m
vmarg.Xms=-Xms1024m
vmarg.Xmca=-Xmca512k
I get regular (3-4+ day) crashes due to Out of Memory errors; trying to expand the underlying memory in the 32 bit shared memory results in instability and increased crash rates. 64 bit w/ better native support for more memory would go a long way towards making my workday less frustrating, more productive, and my clients happier.
I develop for XPiNC applications.
Also the Notes Client 64 bit!
I would not expect to much performance boost from 64bit alone.
Just being able to allocate memory beyond 4 GB would give only incremental performance benefit.
On the other side this sounds like a lot of work..
It is slow because the Notes client is single-threaded.
+ Eclipse...