Closed Bug 13303 Opened 21 years ago Closed 19 years ago

Gratuitous use of strings for storing booleans in registry

Categories

(Core Graveyard :: Profile: BackEnd, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: shaver, Assigned: ccarlen)

Details

(Keywords: perf)

The profile manager is using strings in the registry to store single bits of
information, such as the migration state of a profile.

nsProfile::GetProfileDir has a good example:

  // Get the value of entry "migrated" to check the nature of the profile
  m_reg->GetString( newKey, "migrated", &isMigrated);

(isMigrated is never subsequently freed, as with a few other registry-returned
strings in that function and others.)

If you were to use integers for "migrated", you'd be able to avoid the memory
management headaches and get a performance win to boot.

To close this bug, you should:
- ensure that you properly free all registry-returned strings
- audit for excessive strdups (see 13298 for an example)
- decide if you're going to switch to GetInt for the boolean attributes.  (If
not, please just note why not in this bug.)

Thanks.


Why not use an int
Assignee: selmer → racham
I don't see any functional reason to store this as a string in the registry.
Blocks: 12696
Status: NEW → ASSIGNED
I will change the migration status flag to an int and take care of other
comments. Thanks. Changing status to assigned.
Target Milestone: M11
Whiteboard: [Perf]
Putting on [Perf] radar.
These bugs are not critical for beta 1, moving out.
No longer blocks: 12696
Keywords: perf
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.
Component: Profile Manager → Profile Manager BackEnd
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Whiteboard: [Perf]
Target Milestone: M15 → M17
Target Milestone: M17 → M19
Moving this to M20.
Target Milestone: M19 → M20
Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
With some work I did on nsProfileAccess.cpp recently, most of this has been
fixed. The booleans were stored as strings in the registry but, worse, they were
kept as strings on being internalized. There were many, many unicode string
comparisons being done to test what should be only a single bit of data. My
changes read the string once, disposed of it, and stored it as a PRBool. I kept
it as a string in the registry itself to avoid compatibility problems.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified code fix
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.