sciteco - Scintilla-based Text Editor and COrrector

Age	Commit message (Collapse)	Author	Files	Lines
2016-11-22	partially reversed/fixed-up b7ff56db631: avoid g_slice allocators and ↵	Robin Haberkorn	1	-14/+22
	performance issues with memory measurements * Fixed build problems on Windows * g_slice on Windows has been shown to be of little use either and it does not work well with the GetProcessMemoryInfo() measurements. Also, it brings the same problem as on Glibc: Not even command-line termination returns the memory to the OS. Therefore, we don't use g_slice at all and commented on it. * The custom Linux and Windows memory measurement approaches have been shown to be inefficient. As a workaround, scripts disable memory limiting. * A better approach -- but it will only work on Glibc -- might be to hook into malloc(), realloc() and free() globally and use the malloc_usable_size() of a heap object for memory measurements. This will be relatively precise and cheap. * We still need the "Object" base class in order to measure memory usage as a fallback approach.
2016-11-20	fixed glib warnings about using g_mem_set_vtable() and revised memory limiting	Robin Haberkorn	1	-0/+168
	* we were basing the glib allocators on throwing std::bad_alloc just like the C++ operators. However, this always was unsafe since we were throwing exceptions across plain-C frames (Glib). Also, the memory vtable has been deprecated in Glib, resulting in ugly warnings. * Instead, we now let the C++ new/delete operators work like Glib by basing them on g_malloc/g_slice. This means they will assert and the application will terminate abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is more important to have a good memory limiting mechanism. * Memory limiting has been completely revised. Instead of approximating undo stack sizes using virtual methods (which is unprecise and comes with a performance penalty), we now use a common base class SciTECO::Object to count the memory required by all objects allocated within SciTECO. This is less precise than using global replacement new/deletes which would allow us to control allocations in all C++ code including Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time checks would be cumbersome. In any case, we're missing Glib allocations (esp. strings). * As a platform-specific extension, on Linux/glibc we use mallinfo() to count the exact memory usage of the process. On Windows, we use GetProcessMemoryInfo() -- the latter implementation is currently UNTESTED. * We use g_malloc() for new/delete operators when there is malloc_trim() since g_slice does not free heap chunks properly (probably does its own mmap()ing), rendering malloc_trim() ineffective. We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't be available elsewhere) and found that it brings no significant performance benefit. On all other platforms, we use g_slice since it is assumed that it at least does not hurt. The new g_slice based allocators should be tested on MSVCRT since I assume that they bring a significant performance benefit on Windows. * Memory limiting does now work in batch mode as well and is still enabled by default. * The old UndoTokenWithSize CRTP hack could be removed. UndoStack operations should be a bit faster now. But on the other hand, there will be an overhead due to repeated memory limit checking on every processed character.