tracker issue : CF-4201938

select a category, or use search below
(searches all categories and all time range)
Title:

QueryNew/QueryAddRow has extreme memory usage / is slow

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/AsDesigned

Reporter/Name(from Bugbase): ALEXANDER HASS / ()

Created: 04/10/2018

Components: Database, CFQuery, Performance

Versions: 2016

Failure Type: Performance Issue

Found In Build/Fixed In Build: Updater 5 /

Priority/Frequency: Normal / All users will encounter

Locale/System: ALL / Windows 10 64 bit

Vote Count: 0

Problem Description: We are using Query quite often and just found that this is extreme slow and also use extreme lot memory.

Steps to Reproduce: Run attached example with 100.000 and 1.000.000 items.

Actual Result: exponential slowliness and transaction allocated memory increase

Expected Result: Low memory usage as ArrayAppend

Any Workarounds: None.

Attachments:

Comments:

comparison b/w arrays and queries is not fair. queries are more complicated data-structures and processing them has greater overheads.
Comment by Piyush K.
27647 | April 28, 2018 07:09:48 PM GMT
What is the solution / bugfix to the performance issue? With array we only said what type of speed and memory usage we expect. Exponential memory usage with id‘s in a single row is not ok nor logic. The code is EXTREME slow. Sooo slow and memory intensive that it becomes impossible to use. What we are doing is not complex and the issue shows up whenever we access something in query cache. Something very common and recommended. It is recommended to save querys in querycache and reuse the cached resultset. The same also happen with query of query as I know. Saving the query to cache is still extreme fast, but accessing cache kills the system. Looks like you have no problem keeping it in memory and saving, but re-reading kills everything. Therefore something goes wrong here. This need to be improved in extreme fassion. Selecting a few id is not memory intensive nor slow.
Comment by ALEXANDER H.
29363 | July 20, 2018 10:52:19 AM GMT