On 04/04/14 12:16, Dimitry Sibiryakov wrote: > 04.04.2014 9:00, Alex Peshkoff wrote: >> In yvalve you were saying absolutely contrary things - to save 2 atomic >> ops you were going to delay deallocation of objects in providers and >> providers themself. > Yes, and I was told (by you) that saving CPU clocks is pointless
Never told this. Instead I've agreed that such argument as avoiding additional atomic ops is always important. But it's definitely more important inside engine in time critical part of it. > but RAM is precious > and should be freed ASAP. Not RAM but resources. But I must say that I've agreed with your suggestion and plan to review that part of yvalve. Not sure I will change it (mentioned approach of releasing provider objects after detach was present before FB3), but that's what worth looking at. >> Here you try to add a lot more of them. > Here I follow your pattern and release memory ASAP. Releasing provider makes memory to be returned to higher memory allocation levels, up to returning it to OS. Returning it to transaction's pool does not do it. >> And remember >> - undo is one of time-critical places in engine, it's not an yvalve. > Undo of update_in_place() and an ordinary undo are two different things. > Only first one > is affected by this patch. > update_in_place() is also used often enough updating same record in one transaction more than once is not something outstanding ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
