Closed thetopic closed 5 years ago
SLL mode failures mean that the parser's faster mode has failed and the parsing of the module is being re-attempted with the slower LL mode. rst![field name]
syntax is shorthand for the longer but more explicit rst.Fields("field name").Value
syntax, which shouldn't fail to parse with SLL.
A lot of care was taken in writing the grammar in such a way that SLL mode would be used as much as possible, however it's not always possible... the bang operator is one of these cases.
We do need quite a bit of memory, since we've prioritized performance over memory savings, so a lot of caching is going on... we do have ideas to improve the memory footprint without hurting performance too much, but the changes required are massive and we're just not there yet.
I've got Rubberduck working fine against a 90-module Excel project, consuming roughly 400MB RAM, but that's on 64-bit Win7 in Office 2010 x86... 100 Access forms might be stretching it, depending on the code-behind and number of controls in each one.
That said, nice to see ducky "working" in OfficeXP! Does it work decently in a new project?
Linking #3347
For information :
Any object (form, report, module) more than 600
Number of active code lines more than 129 000
Just for reference why an out of memory error occurs for much less memory consumption than the memory you have installed. Since the Office running is a 32 bit application, it will never see more than a little short of 2 GB of memory.
More precisely, it will not be able to use more memory for two reasons. First, the developers of Office apparently did not set the LARGEADDRESSAWARE
flag. (Otherwise, the limit would be 4 GB on a 64bit system.) Second, we do not go through the hoops to map address spaces to other memory regions and swap the address spaces as needed, which is rather tedious and error prone.
Closing this in favor of tracking the issue previously referenced (#3347 )
Good Morning,
When I start processing at first it works, the processor is used at more than 75% (I have 8 cores) and writing to the log is done regularly (TRACE level enabled 1 second for a form) but memory consumption increases little by little (I have 16GB), but once the memory consumed by Access reaches 1GB the processor consumption stagnates at 13% and writing to the log is very slow (several minutes for a form) and I have an exception :
Othe thing, I don't know if this is normal but in the log when TRACE is enabled I have hundreds of errors of this type:
It matches this type of code:
Rst![Field_To_Retrieve]
Version 2.2.6738.40126 Système d'exploitation : Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Produit hôte : Microsoft Office XP x86 Version hôte : 10.0.2627 Exécutable hôte : MSACCESS.EXE