Anteru's blog
  • Consulting
  • Research
    • Assisted environment probe placement
    • Assisted texture assignment
    • Edge-Friend: Fast and Deterministic Catmull-Clark Subdivision Surfaces
    • Error Metrics for Smart Image Refinement
    • High-Quality Shadows for Streaming Terrain Rendering
    • Hybrid Sample-based Surface Rendering
    • Interactive rendering of Giga-Particle Fluid Simulations
    • Quantitative Analysis of Voxel Raytracing Acceleration Structures
    • Real-time Hybrid Hair Rendering
    • Real-Time Procedural Generation with GPU Work Graphs
    • Scalable rendering for very large meshes
    • Spatiotemporal Variance-Guided Filtering for Motion Blur
    • Subpixel Reconstruction Antialiasing
    • Tiled light trees
    • Towards Practical Meshlet Compression
  • About
  • Archive

First bug tracker image

February 17, 2005
  • Programming
  • Web
approximately 2 minutes to read

Lately, I took a closer look at the bugtracker, and entered some sample data into the database. Here you can see the current bug detail page: Detail page, 35kb. Hopefully I’ll be able to create the enter bug page tomorrow. By the way, ordered a new PSU, hopefully I’ll be able to start my new comp next week. Fingers crossed :) The bugtracker is currently designed with the following target plattform in mind: Apache 2.0 (maybe I’ll use mod_rewrite to get pretty links like bugtracker/bug/232 instead of bug.php?id=232), PHP5 (as it’s quite object oriented, and I plan to use the XML extensions) and PostgreSQL (as it has foreign keys, views and is very reliable).

The target browser is Firefox, as it’s my primary browser and I hate working around IE’s CSS quirks and bugs. It’s getting on pretty well, less problems than I expected. There is still a small design problem: All more or less static data like the various priority levels are also stored in the DB and read out every time for example the bug page is called - though they don’t change. Their purpose is to serve as foreign key targets, and I think I’ll put all those queries (8 by now) into a special cache class that is only updated when the data in the database changes, and otherwise it’ll run directly from disk, saving those 8 queries. I’m quite curious to see how much faster it’ll get, as the database is very fast. I think I won’t cache the various program versions. They also don’t change often, too, but they aren’t needed in every report page, so it won’t be a big deal when they’re loaded from time to time.

Something interesting I found out in this context: Let’s assume you have a table with two columns, id and name and you have a query like that: SELECT * FROM table;. This code does run around half as fast as this one: SELECT id, name FROM table;. The server load is higher, anyway, the result set was returned twice as fast (only 7 rows). This is tested with PostgreSQL 8.0.0 under Windows XP with enough RAM to hold the whole database. Quite strange, but I use the second style anyway for the sake of clarity.

Previous post
Next post

Recent posts

  • Data formats: Why CSV and JSON aren't the best
    Posted on 2024-12-29
  • Replacing cron with systemd-timers
    Posted on 2024-04-21
  • Open Source Maintenance
    Posted on 2024-04-02
  • Angular, Caddy, Gunicorn and Django
    Posted on 2023-10-21
  • Effective meetings
    Posted on 2022-09-12
  • Older posts

Find me on the web

  • GitHub
  • GPU database
  • Projects

Follow me

Anteru NIV_Anteru
Contents © 2005-2025
Anteru
Imprint/Impressum
Privacy policy/Datenschutz
Made with Liara
Last updated February 03, 2019